Incident categorization plays a bigger role in cybersecurity operations than most people realize. It affects how alerts are routed, how incidents get reported, and how security programs measure what’s actually happening in their environment. But the taxonomies used to label these events are often inconsistent, vague, or misaligned with real-world attacker behavior. In this post, I summarize earlier research I wrote up over the past year, in which we walk through a structured comparison of three major frameworks—DoD, CISA, and Verizon DBIR—and introduce an alternative approach called UCIT. It’s designed to be clearer, more usable under pressure, and better suited for modern SOC workflows. I also tested it against 100 realistic attack scenarios to see how it holds up.

Introduction

The moment a cyber incident is detected, it enters a pipeline of documentation, escalation, and eventual reporting. Whether it’s a beacon to an external IP, a suspicious PowerShell command, or a compromised web application, that event needs to be labeled—and the frameworks organizations use to apply those labels carry significant weight. Unfortunately, many of the most commonly used taxonomies fail to clearly or consistently describe what’s actually been observed.

The result isn’t just inconsistent naming, it’s mismatched expectations. Categories that sound specific on paper often collapse into vague or overlapping buckets in practice. Terms like “Malicious Logic” or “Unauthorized Access” may tick a policy box, but they often lack the precision needed to interpret or compare incidents meaningfully over time. What’s ultimately reported may bear little resemblance to what was actually detected, investigated, or remediated.

Most security teams rely on some form of incident categorization schema to manage this process. These frameworks—whether formal policies, inherited templates, or internal conventions—are designed to classify cyber incidents into discrete types. Over time, these categories become embedded in workflows, tooling, and compliance processes. Ideally, they should promote clarity, consistency, and better decision-making. In reality, they often do the opposite.

Few organizations use the same schema. Definitions vary from one framework to the next, and even within the same system, multiple categories can seem equally applicable. Some frameworks offer rigid, technical definitions that collapse under operational reality. Others are so vague that nearly any event could fit under multiple labels. When analysts are forced to make sense of complex incidents using a taxonomy that doesn’t quite fit, the result is mislabeling, inconsistent tracking, and confusion that echoes through every layer of the response process.

These mismatches matter. They introduce noise into long-term trend analysis, skew threat intelligence reporting, and complicate inter-team or inter-organizational collaboration. As cyber operations scale and mature, the lack of a consistent, usable labeling system becomes more than a clerical nuisance—it becomes a structural risk.

This blog post is the product of a year-long effort to assess and compare three of the most visible public incident taxonomies: those published by the Department of Defense, CISA, and Verizon. To evaluate their accuracy, clarity, and practical value, I tested each one against real-world adversary behavior as defined in the MITRE ATT&CK framework. The findings reveal a set of common pitfalls, structural mismatches, and design decisions that consistently get in the way of clear, usable incident reporting.

This resulted in the development of a new taxonomy (cue the relevant XKCD comic here, of course) that I am calling the Universal Cyber Incident Taxonomy (UCIT). Originally, I thought I’d have to come up with some sort of new system, but what I found is that MITRE ATT&CK just simply works for this too – so it is basically retrofitting that framework into how we label our events in an incident management system. The result is a simple taxonomy, inspired by the Linnaean model (Kingdom-Phylum-Class-etc), that seems to more accurately identify the event and makes it much more useful for retrospective trending and SOC process improvement.


Don’t mind me, just contributing to the problem

And to clarify - this taxonomy isn’t intended to replace a full incident report, nor does it aim to capture every contextual detail required for regulatory disclosure or postmortem analysis. Organizations will still need supplementary fields for indicators, timelines, systems impacted, response steps, and lessons learned. Rather, UCIT is designed to serve as a standardized short-form naming convention—a structured label that conveys, at a glance, what type of incident has occurred, how it manifested, and what level of access or compromise was observed. It treats the incident as a discrete object within a broader system of analysis, making it easier to sort, search, and compare events with a measured improvement in clarity and consistency.

Before diving into the specifics of each framework, it’s worth unpacking why this problem persists and what makes incident categorization—something so foundational—so difficult to get right.

Why Incident Categorization Still Sucks

For all the progress made in detection, automation, and response, the simple act of categorizing cyber incidents remains surprisingly error-prone. In a typical SOC, it’s not unusual for two different analysts to label the same event in different ways, each following the official guidance provided by their organization. These inconsistencies aren’t just artifacts of human error—they’re baked into the structure of the taxonomies themselves.

Many frameworks in use today are either too broad or too brittle. Some are carryovers from regulatory checklists. Others evolved organically inside a single organization and were never meant to scale. Even well-known guidance, like the DoD’s CJCSM 6510.01B or CISA’s federal reporting model, often struggles when applied to ambiguous or fast-moving incidents. Instead of clarifying what happened, they leave analysts guessing which category is “close enough.”

The effects are cumulative. Misclassified incidents distort organizational metrics, weaken long-term threat modeling, and make root cause analysis harder than it needs to be. For incidents that span multiple environments—or require escalation to external partners—mismatched labels can delay response or trigger unnecessary friction between teams. Internally, the same confusion slows investigations, increases duplication, and undermines confidence in the data being used to guide strategy and investment.

The problem gets worse the earlier an incident is detected. Initial access and execution techniques often unfold before the full scope of the attack is known. Analysts working with limited information are still expected to assign a category, even though that classification may shift significantly as the investigation develops. Some frameworks try to account for this with “placeholder” categories like “Investigating” or “Unknown,” but these catch-alls offer little value for retrospective analysis and can become data sinkholes over time.

A well-designed taxonomy needs to serve two very different purposes: it must be usable in real time, when clarity and speed are essential, and also meaningful later on, when analysts and leadership rely on the data for analysis, reporting, and decision-making. Most existing systems struggle to strike that balance. They either overfit the operational need and lose analytical power, or prioritize specificity and end up too complex to use effectively during an actual event.

This study began as a way to test whether any of the most commonly referenced frameworks could offer a better approach. By mapping a large sample of MITRE ATT&CK techniques to each schema’s incident categories, it became possible to observe where definitions overlapped, where gaps emerged, and where labels broke down entirely. The goal was not only to identify flaws, but to use those findings as the foundation for something better.

The inconsistencies observed across these frameworks aren’t just theoretical. To better understand how they function in practice, I conducted a structured assessment of three widely used taxonomies: the Department of Defense’s CJCSM 6510.01B, CISA’s Federal Incident Notification Guidelines, and Verizon’s Data Breach Investigations Report (DBIR) categorization model. I should note that these are the three largest ones I could find that are publicly available. For Verizon in particular, it’s possible that internally other taxonomies are utilized. For CISA, I suspect this taxonomy was adapted because it had to deal with dozens to hundreds of different organizations translating their taxonomies into something CISA could ingest cleanly. In any case, I used what I could cite.

Department of Defense (CJCSM 6510.01B)

Structure: A structured model using numerical categories (CAT1–CAT9), each representing different incident types such as insider threat, malicious logic, and user-level intrusion.
Purpose: Designed to support DoD-wide incident handling processes, with formal escalation and reporting across components.
Strengths: Offers granularity and aligns with internal DoD requirements; integrates technical detail like privilege level.


The DoD Framework, unchanged since 2014

CISA (Federal Incident Notification Guidelines)

Structure: A lightweight, impact-focused notification framework, including categories like Functional Impact, Information Impact, and a catch-all “Unknown”.
Purpose: Facilitates rapid, standardized reporting by federal agencies to NCCIC/US‑CERT, especially under regulatory or operational directives.
Strengths: Simplicity enables quick compliance and alignment with recovery and impact metrics.


CISA, trying to work with every single framework

Verizon (DBIR Classification Schema)

Structure: Industry-facing categories derived from the VERIS framework, including labels like “System Intrusion,” “Privilege Misuse,” and “Denial of Service,” based on clustering of incident data.
Purpose: To classify breach and incident data at scale for annual reporting, trending, and risk analysis across industries.
Strengths: Categories are intuitive and reader-friendly, useful for high-level reporting and communication trends.


This might only be used in the DBIR but I didn’t have many frameworks to choose from

Rather than relying on anecdotal impressions, the evaluation used a grounded and repeatable method: comparing how each framework handled a broad selection of real-world attack techniques, as documented in the MITRE ATT&CK framework. This crosswalk approach allowed for a direct, apples-to-apples comparison of how each schema defines, interprets, and sometimes struggles to categorize adversary activity.

How The Frameworks Were Tested

MITRE ATT&CK has become the industry standard for classifying adversary behavior. With over 500 techniques and sub-techniques spanning the entire attack lifecycle, it offers a detailed map of how real intrusions unfold—from initial reconnaissance to impact. Because each technique is well-defined and tied to observable behaviors, it provides an ideal reference point for evaluating incident taxonomies.

The goal of this study was to see how well-known categorization schemas perform when applied to these techniques. In other words, if an analyst detected a known ATT&CK technique in their environment, how would they label it under each of the three frameworks? Would the category be clear, accurate, and consistent? Or would it introduce ambiguity, overlap, or blind spots?

To test this, I selected 86 techniques from across all 14 MITRE ATT&CK tactic families, ensuring coverage of the full attack lifecycle. Each technique was then mapped—manually but methodically—to the most appropriate category or categories within the CISA, DoD, and Verizon taxonomies. The goal wasn’t to force a one-to-one match, but to simulate how a typical SOC analyst would be expected to categorize the activity using only the guidance provided in each framework.

This notional mapping exercise revealed exactly where the definitions aligned, where they conflicted, and where gaps emerged. It also made visible a set of recurring patterns that suggest deeper structural issues—some tied to terminology, others to the underlying assumptions baked into each model.

In each case, the mapping reflected the most plausible category an analyst might choose based on the language and guidance available within that framework. When techniques could reasonably fall into multiple categories—such as a malicious macro that leads to both initial access and code execution—the analysis prioritized the label most likely to be used early in an incident response workflow. While this approach doesn’t capture every nuance of a live investigation, it mirrors the practical conditions under which these frameworks are typically applied.

In fact, the nuance and ambiguity when labeling was sort of the point. Deep diving the labeling decisions should result in disagreement, since this was ultimately the intent of the study. Anecdotally knowing that these schemas were imperfect was the genesis of the study in the first place. The outcome ultimately aimed to solve as much of that ambiguity as possible, as well as offer a viable and open-source alternative designed for wider adoption.

Where the Taxonomies Fail

Once the ATT&CK techniques were mapped to each framework, patterns began to emerge—some predictable, others more surprising. While each taxonomy had strengths, all three struggled with consistency, clarity, and completeness in different ways. The further we got from traditional attack types like malware or phishing, the more obvious the gaps became.


Mapping Recon, Initial Access and Execution

One of the most striking examples came from the CISA schema. Designed to help federal agencies rapidly categorize and report incidents, its model includes a category called “Other” with a sub-option labeled “Unknown.” In practice, this became a kind of dumping ground. When post-compromise behaviors like lateral movement, credential dumping, or command-and-control activity didn’t cleanly fit into any of the other categories, they defaulted into Unknown—not because they were unclear to the analyst, but because the schema itself had no better place for them.


Mapping Persistence, Priv Esc and Defense Evasion

This issue didn’t just happen once or twice. Across the full mapping, “Unknown” became one of the most frequently selected categories in the CISA model. That’s not a reflection of analyst uncertainty; it’s a reflection of a taxonomy that wasn’t built with the possibility of detection at various stages in the attack chains in mind. The earlier stages of the ATT&CK kill chain—initial access, phishing, web exploitation—were covered reasonably well. But the moment an attacker moved deeper into an environment, the framework’s descriptive power started to fall apart. Analysts may be detecting attacks at any portion of the kill-chain, and the taxonomy simply does not reflect that.


Mapping Credential Access, Discovery and Lateral Movement

The DoD’s CJCSM 6510.01B schema performed better in terms of granularity, but had problems of its own. The model uses a numerical category system (CAT1 through CAT9), where each number represents a different type of incident. While this can be efficient for quick classification, the boundaries between categories are blurry. For example, CAT2 covers “User-Level Intrusion,” while CAT7 is “Malicious Logic.” Depending on the interpretation, the same activity—say, a user opening a malicious attachment that drops a backdoor—could reasonably fall under either. As with the CISA model, this led to mapping collisions and disagreements, especially in scenarios where attacker action and malware overlapped.


Mapping the rest of them

Then there’s Verizon’s DBIR schema. It offered the most modern and streamlined set of categories, namely for its simplicity—terms like “System Intrusion,” “Privilege Misuse,” and “Denial of Service”—which were intuitive on the surface but too broad in practice. “System Intrusion” alone ended up absorbing nearly every post-access technique in the ATT&CK framework, turning it into a catch-all not unlike CISA’s “Unknown.” The lack of subcategories made it easy to classify something quickly but hard to draw meaningful distinctions between types of adversary behavior. As a result, the schema produced clean-looking data at the cost of useful detail.

In all three frameworks, ambiguity wasn’t just a fringe problem—it was structural. Key ATT&CK techniques simply didn’t map cleanly to any category, or mapped to too many. Post-compromise behaviors in particular—things like internal reconnaissance, credential access, and lateral movement—were consistently underserved or blurred across multiple definitions. These stages are often the most critical to identify and contain, yet they were the hardest to label in a consistent, actionable way.

Even where the frameworks offered sufficient options, they often lacked clear guidance. Descriptions were vague, examples were outdated, and few models acknowledged that techniques evolve or overlap. This absence of context forced analysts to make judgment calls, leading to inevitable variation in how similar activity was reported over time—or across teams.

These aren’t theoretical issues. In a live SOC, the cost of mislabeling is real. Categorizing a credential dump as “System Anomaly” instead of “Unauthorized Access” might change who responds. Filing C2 traffic under “Unknown” could mean it’s deprioritized or missed entirely. Over time, these misclassifications shape the organization’s view of what kinds of threats it faces, and whether its defenses are working.

The takeaway is simple: even the most widely used frameworks struggle to keep pace with how adversaries operate today. They either offer too little structure or too much, and rarely the right kind. Each of the three models studied here exposed different weaknesses—some tied to their origins, others to assumptions that no longer hold up. But the cumulative result is the same: analysts are left trying to fit square pegs into round taxonomies, and the data suffers because of it.

Framework	Strengths	Primary Weaknesses	Common Failure Points (from ATT&CK Mapping)
CISA (Federal Guidelines)	Familiar to government teams; covers initial access types well	Over-reliance on “Unknown” category; lacks depth for post-access behavior	Credential Access, Lateral Movement, C2, Discovery
DoD (CJCSM 6510.01B)	Structured model (CAT1–CAT9); granular at the policy level	Overlapping categories; ambiguous boundaries; DoD orgs may be interpreting/labelling differently	Malicious Logic vs. User Intrusion; Execution vs. Exploitation
Verizon (DBIR Schema)	Simple, intuitive categories; popular in industry reporting	Overgeneralization; limited category resolution; no real-time guidance	“System Intrusion” overuse; lack of precision for recon and privilege escalation

What a Good Taxonomy Should Do

After seeing how each of the three major frameworks struggled under pressure, the question became less about what was wrong and more about what would actually work. If incident categorization is going to be useful—operationally and strategically—it has to meet a fairly specific set of demands.

First and foremost, a good taxonomy should be usable in real time. Analysts working an active case shouldn’t have to second-guess what label to apply or cross-reference a 60-page policy document to find the right fit. The categories need to make intuitive sense and reflect how incidents actually unfold in modern environments. That means capturing behavior, not just outcomes, and doing so in a way that supports triage, escalation, and decision-making without slowing things down. Crucially, the taxonomy must also account for point-in-time reporting—the idea that labels are often assigned early, before the full scope of the incident is known. These provisional classifications are necessary to maintain speed and responsiveness, but they need to be flexible enough to evolve as new information emerges. Otherwise, early labels become permanent artifacts that fail to reflect the actual nature of the incident once fully understood.

At the same time, a taxonomy needs to hold up after the fact. Once the dust settles and an investigation is closed, that incident label becomes part of the permanent record. It shows up in monthly dashboards, annual reports, and threat trend summaries. If the label is too vague or inconsistent, it can distort analysis or make it harder to spot recurring patterns. A good taxonomy must strike a balance between simplicity and resolution—clear enough for operational use, detailed enough for strategic value.

Flexibility is also critical. Adversary behavior changes constantly, and new techniques emerge faster than most documentation cycles can keep up with. Taxonomies that assume a fixed set of categories will always be playing catch-up. Instead, the structure should be designed to evolve. That might mean using parent-child relationships between categories, allowing for modular additions, or supporting layered labels that can reflect both known and emerging threats.

Consistency matters, but so does shared language. One of the biggest barriers to collaboration across teams or agencies is semantic drift—when two groups use the same term to mean different things, or different terms to describe the same behavior. A well-designed taxonomy needs to reduce that ambiguity, either by aligning with existing standards like MITRE ATT&CK or by clearly defining its own terms in a way that practitioners can agree on.

Lastly, a usable schema needs to be open and adaptable. Proprietary systems or black-box logic might work internally, but they don’t scale across industries, vendors, or jurisdictions. Security teams need a framework they can apply without licensing fees or lengthy onboarding—and ideally, one they can contribute to or adjust based on their specific operational context.

None of the three frameworks examined in this study fully met these criteria. Some were better than others in specific areas, but all fell short in balancing clarity, coverage, and real-world usability. That gap is what led to the creation of a new model—one designed from the ground up to address these shortcomings, and to offer a practical, open-source alternative for incident classification that actually works in the environments analysts are defending today.

Introducing UCIT — A Smarter Taxonomy

The Universal Cyber Incident Taxonomy (UCIT) was developed as a direct response to the limitations uncovered during this study. Rather than trying to retrofit outdated frameworks, UCIT was designed from the ground up to reflect how incidents unfold in real-world SOC environments—across time, across teams, and under uncertainty.

At its core, UCIT introduces a trinomial naming convention inspired by Linnaean taxonomy in biology. In that model, organisms are categorized hierarchically (e.g., Genus species subspecies) to reflect both general groupings and specific distinctions. UCIT applies this structure to cyber incidents, using three components to capture the nature, behavior, and observed impact of an event at the time it is reported:


UCIT and it’s hierarchal taxonomy approach

Incident Category – a broad label representing the type of event (e.g., System Intrusion);
MITRE ATT&CK Technique Family – describing the behavioral mechanism observed (e.g., Command and Control);
Level of Compromise – indicating the access level at time of detection (e.g., User, Root, or Unknown).

This structured approach enables compact but expressive incident records. For instance, a report written following an alert based on beaconing activity observed on a workstation could be labeled:
System Intrusion – Command and Control – User

That simple string tells analysts and leadership what happened, what phase of the intrusion it reflects, and what kind of access the adversary appears to have—all without requiring an in-depth narrative or post-hoc synthesis. It also informs the investigation, and in which directions of the kill-chain must still be investigated and documented.

One of the key design goals of UCIT is to support point-in-time classification. Most incidents begin with partial visibility. Analysts see a symptom—an execution, a login, a traffic pattern—before they understand the full scope or origin. UCIT’s structure embraces this uncertainty rather than masking it. It encourages timely, structured labeling of what is known now, with the understanding that the event record can be expanded later without requiring the original label to be rewritten or invalidated.

To avoid excessive granularity and promote operational alignment, UCIT favors MITRE ATT&CK tactic families over individual sub-techniques. While sub-techniques offer rich detail, they aren’t practical for everyday use in SOC workflows or high-volume environments. Tactic families provide a stable middle ground: granular enough to reflect behavioral context, but general enough to avoid forcing analysts into overly specific judgments too early.

Similarly, UCIT borrows the concept of compromise level from the DoD’s schema, distinguishing between User, Root, and Unknown. This offers meaningful clarity during early triage without pressuring analysts to speculate about the adversary’s full capabilities prematurely.

However, the design also accounts for a crucial limitation of point-in-time labeling: once an incident is fully investigated and closed out, the original label may no longer capture the full arc of what actually occurred. For example, a detection of a T-1189 Driveby Compromise initially categorized as System Intrusion – Initial Access – User might later be found to have culminated in the deletion of critical files (T1485 - Data Destruction). Retaining only the initial label would obscure that outcome—and limit the analytical value of the record.

To address this, UCIT allows for the closeout “Final Observed Tactic” field to be added at incident close-out. This enables organizations to track both the entry point and end state of the incident in a structured way. In the drive-by example above, the final record could be closed out with:

UCIT Label: System Intrusion – Initial Access – User
Final Observed Technique: Impact

This preserves the integrity of early-stage reporting while giving incident responders a way to reflect the full attack path in their postmortem documentation. Over time, these final-state annotations can also be used to build more accurate metrics about adversary success rates, common intrusion sequences, and detection gaps.

Separately from the study to further evaluate how UCIT performs across a broad range of real-world conditions, I also applied the model to a dataset of 100 distinct cyber incidents. These scenarios, grounded in known adversary behavior and mapped to MITRE ATT&CK techniques, were each labeled using UCIT alongside DoD, CISA, and Verizon DBIR. This comparative exercise highlighted UCIT’s flexibility and interpretability—particularly its ability to represent incidents clearly regardless of where detection occurred in the kill chain. Just as importantly, it demonstrated that UCIT can function as a consistent shorthand for incident classification, even when applied at scale across diverse attack types. That raw data is available here.

Finally, UCIT is currently being tested in a handful of live SOC environments, where analysts are applying it alongside their existing categorization model. Initial feedback suggests that the trinomial structure improves consistency across teams, reduces the misuse of vague categories like “Unknown,” and helps streamline communication between tiers of the incident response process.

In short, UCIT isn’t just another naming convention—it’s a flexible, modular framework built to reflect the actual lifecycle of incident detection, response, and closure. It offers clarity without rigidity, structure without overhead, and, most importantly, it’s designed to meet analysts where they are: under pressure, in the moment, and trying to get things right.

A Note on “Non-Compliance Activity”

While the UCIT model includes Noncompliance Activity as one of its three top-level categories, this class of incidents was intentionally left out of scope for the comparative framework analysis conducted in the original study. The goal of the research was to evaluate incident categorization schema against adversary behaviors, using MITRE ATT&CK as a reference point. Since ATT&CK focuses exclusively on malicious techniques rather than policy violations or configuration drift, there was no consistent baseline against which to evaluate noncompliant events.

That said, Noncompliance Activity remains an essential part of the UCIT structure. It serves as a placeholder for incidents that may not involve malicious actors, but still represent a breakdown in security controls or organizational policy. These could include:

Unauthorized software installation,
Use of prohibited protocols,
Insecure system configurations,
Accidental data exposure,
Or repeated deviation from access management policies.

Because definitions of “noncompliance” vary significantly between organizations—depending on regulatory environment, internal governance, and acceptable use policies—UCIT leaves the second and third labels in this category intentionally flexible. Rather than prescribing a fixed vocabulary, it’s expected that organizations will populate their own internal subcategories based on relevant standards and priorities.

For example, one environment might use:

Noncompliance – Policy Violation – User
Noncompliance – Configuration Drift – Root

While another might adopt labels like:

Noncompliance – Data Handling – Unknown
Noncompliance – Unauthorized Application – User

This design reflects UCIT’s underlying philosophy: to provide just enough structure to enforce consistency, without forcing artificial alignment to one organization’s policy framework. By accommodating policy-based incidents within the same naming model as malicious activity, UCIT helps unify reporting streams and gives leadership a more complete view of both threat activity and control enforcement.

Noncompliance Activity might not map cleanly to threat intelligence or adversary behavior, but it belongs in the same operational picture. Security posture isn’t defined solely by what adversaries do—it’s equally shaped by internal discipline, misconfiguration, and the edge cases where controls fail quietly. It’s also consistent across all the tested taxonomies and is arguably used across all SOCs as some level of incident categorization. UCIT gives those cases a place to live, without forcing them to compete for space with intrusion data or be filed away under “Other.”

Why UCIT Works

One of the reasons UCIT holds up under operational pressure is that it doesn’t try to solve everything at once. By front-loading the taxonomy (inspired heavily by the Verizon DBIR model) with a limited number of high-level categories —Boundary Action, System Intrusion, and Noncompliance—it forces a cleaner separation of concerns. Analysts aren’t expected to determine exactly how something happened in the first moments of detection; they’re simply identifying what type of activity they’re observing in broad terms.

This helps reduce classification clutter. Instead of arbitrarily distinguishing between similar incident types (e.g., credential abuse versus malware delivery versus internal misuse) with overlapping definitions, UCIT anchors the label in the broader context: was this activity observed at a boundary, was it already inside the system, or does it reflect something misaligned with policy or configuration? That top-level split eliminates a lot of unnecessary debate and brings more consistency to operational reporting.


Testing Scenario INC-136, observed C2

Where the taxonomy becomes more expressive is in the second label, which references a MITRE ATT&CK technique family. This choice is important. By focusing on families rather than individual techniques or sub-techniques, UCIT preserves behavioral context without overwhelming the analyst with granularity. These technique families—like Execution, Credential Access, or Exfiltration—are widely recognized and integrate well with existing detection logic and threat modeling practices.

The real utility of this approach becomes clearer as it is essentially acknowledging that any incident report is inherently point-in-time reporting. Initial detection rarely comes with full visibility. A SOC might see C2 activity before they ever see how the attacker got in. In those cases, UCIT allows the analyst to label the event based on what’s been observed—without having to speculate about origin, intent, or end-state. That same labeling structure then supports investigation in both directions. If the detection is late in the kill chain, the behavioral tag tells responders where to pivot upstream. If it’s early, it provides context for what to monitor next and how the attack might progress.


Testing Scenario INC-135, observed FTP brute force

This forward-and-backward utility isn’t just helpful for incident handlers. It also creates a shared reference point that’s legible to stakeholders who aren’t part of the response team. A label like System Intrusion – Credential Access – User communicates more than a simple category or a one-word incident type ever could. It tells leadership what was found, where it occurred, and how deep it appears to go—all in a standardized format that aligns with known adversary behaviors.

Over time, this structure also improves aggregate analysis. The consistent use of a bounded top-level category, combined with structured behavioral and privilege-level descriptors, allows organizations to track trends in attacker behavior without relying on loosely defined “incident types.” This reduces noise in long-term metrics and supports more accurate assessments of threat exposure and defensive coverage.


Testing Scenario INC-148, remote file inclusion to webshell

In addition to supporting point-in-time classification, UCIT’s close-out Final Observed Sub-Technique field introduces meaningful advantages for retrospective analysis. While initial labels reflect what was known at the time of detection, the final sub-technique captures the end-state of the incident once it’s been investigated and closed. This distinction allows organizations to preserve the operational reality of early-stage triage while still building accurate historical records that reflect full attack progression.

Over time, consistently applied final sub-techniques provide a richer dataset for key performance indicators (KPIs). Rather than just tracking volume or category counts, SOCs can begin to analyze trends in attacker success—what tactics most commonly lead to impact, where detection occurs relative to the intrusion lifecycle, and which behaviors are most likely to be missed until later stages. This enables more meaningful insight into detection effectiveness and response timing.


Testing Scenario INC-126, DDoS of login portal

For example, if the majority of incidents initially detected as System Intrusion – Execution – User are ultimately closed with a sub-technique of Data Exfiltration, that points to a need for improved detection earlier in the chain—possibly at credential abuse or lateral movement stages. On the other hand, a trend showing that most incidents are closed out still within the initial tactic family suggests containment is working effectively, even if initial labeling was incomplete.

These records also serve as a valuable resource for assessing SOC maturity. By comparing initial classification to final resolution, teams can evaluate how quickly and accurately investigations converge on root cause. A high divergence rate between early labels and final sub-techniques might suggest that detection workflows are reactive, or that visibility gaps are forcing excessive rework. Conversely, alignment between initial and final classification can serve as a proxy indicator for high-fidelity detection and investigative discipline.

From a process improvement standpoint, this offers practical insight: Are analysts relying too heavily on general categories? Are cases being reopened due to incomplete scoping? Are certain behaviors consistently flying under the radar until damage is done? UCIT provides a structured, low-friction way to surface these patterns—not just for reporting or compliance, but for internal feedback loops that can drive better tooling, better training, and better outcomes over time. If the initial detection mechanism clusters towards “Execution” and rarely identifies “Initial Access”, does that mean the SOC has a visibility layer problem or an analyst skill issue problem? This labelling convention enables those questions.

While UCIT doesn’t solve every reporting problem, its structured, layered format addresses several of the core limitations surfaced in this study. It supports real-time use without sacrificing analytical clarity, handles uncertainty without erasing context, and produces incident records that are easier to interpret across technical and non-technical boundaries.

Final Thoughts

The goal of this work was never just to critique existing frameworks—it was to understand why incident categorization continues to create friction in environments that already operate under pressure, and to propose something that reflects how incidents actually unfold in the field.

The findings from the comparative analysis made that case clearly enough: major taxonomies like those from CISA, the DoD, and Verizon each bring something useful to the table, but all of them struggle in the same ways. They ask too much of analysts too early, conflate technical behaviors with response impact, and rely on rigid or ambiguous definitions that fail to hold up during real-world detection and response.

UCIT was developed to address those problems—not through more complexity, but through structured simplification. By keeping the top-level category set narrow and deferring behavioral context to a familiar schema like MITRE ATT&CK, it creates a taxonomy that is easier to use, easier to adapt, and easier to scale. Its support for point-in-time reporting makes it useful in active response. Its final-state extension makes it useful for metrics. And its consistency across levels of detail makes it legible to everyone from junior analysts to senior leadership.

That doesn’t mean UCIT is finished. Like any operational model, it benefits from iteration. The structure is openly published so it can be tested, extended, and challenged. Some organizations may want to refine it for their own environment. Others may find value in aligning it to red team operations, audit reporting, or regulatory disclosure. That’s by design.

The broader takeaway here isn’t just about one framework. It’s about recognizing that incident labeling is a strategic function, not just a box to check. Labels shape metrics. Metrics shape investment. If the label is wrong, everything downstream is distorted. UCIT doesn’t guarantee precision, but it helps teams start with clarity, structure, and enough shared language to make decisions faster—and defend them later.

You can read the whole study right here.