When Low-Severity Security Incidents Become High-Value Investigative Intelligence

A guard at a corporate campus logs a tailgating attempt at 7:42 a.m.: someone without a visible badge slipped through a door held open by an employee, was challenged, gave a plausible excuse about a forgotten access card, and left before anyone could verify who they were. The guard writes it up, tags it low severity because no property was taken and no one was threatened, and closes it before lunch. Nothing about that decision is wrong. There was no ongoing danger to respond to, no reason to hold resources against it, and the SOC has real incidents competing for attention that day. The problem is what happens to the report after it closes: it goes into a queue with hundreds of other low-severity tickets, unlinked to the suspicious vehicle logged in the same parking structure six weeks earlier, unlinked to the badge reader that recorded three failed access attempts at a side entrance the following month. Each of those records was handled correctly on its own terms. None of them was ever looked at next to the others.

That gap is not a training failure or a lazy analyst. It is what severity-based triage is designed to do.

Triage Was Built to Allocate Response, Not to Preserve Signal

Severity classification exists to solve a resource allocation problem: when a control room has finite dispatchable attention, it has to decide in seconds which incidents get an officer, which get a phone call, and which get a note in a log. Grading a tailgating attempt, a single suspicious vehicle, or a failed access swipe as low severity is the correct operational call, because none of those events, standing alone, indicates active harm. But severity is a judgment about urgency, not a judgment about information value, and most incident management systems treat the two as the same field. Once a ticket is closed as low severity, it typically stops being examined, cross-referenced, or resurfaced unless another incident forces someone to go looking for history. The individual record is preserved, technically, but it is functionally discarded: nobody is tasked with reading it again in the context of everything else that happened that quarter.

This is a structural property of case-based systems built around one incident, one ticket, one disposition. Reconnaissance, insider threat behavior, and pre-attack surveillance do not announce themselves as single events that cross a harm threshold. They accumulate as a series of individually unremarkable touches across time and location, which is exactly the category of data severity-based triage is built to move past quickly.

What the Record Shows When Someone Goes Back and Aggregates

The clearest evidence for this comes from research that has gone back after the fact and asked what was visible before violence occurred, not what was dramatic, but what was merely present.

The U.S. Secret Service’s National Threat Assessment Center studied 173 targeted attacks in public and semi-public spaces between 2016 and 2020 and found that 65 percent of attackers had exhibited behavior that elicited concern in others before the attack, and 57 percent of those behaviors were serious enough that the observer feared for someone’s safety¹. But the report’s more instructive finding is about the behaviors that fell short of that. It found that 52 percent of attackers displayed what the analysis called “contextually concerning behaviors,” a “constellation of lower-level behaviors” including unusual statements, erratic conduct, and uncharacteristic changes in demeanor, each of which would have required additional information and analysis to know whether it mattered at all². More than half of attackers (54 percent) showed behavior spanning three or more distinct categories of concern, not one dramatic red flag but several small, disconnected ones². The report’s own framing after 25 years of this research is direct: these acts are rarely spontaneous and are almost always preceded by warning signs observed piecemeal by different people¹².

The Marjory Stoneman Douglas High School Public Safety Commission’s investigation into the 2018 Parkland shooting is a documented case of exactly this failure of aggregation rather than a failure of any single response. The Commission found the Broward Sheriff’s Office had 49 recorded reports connected to the shooter or his address before the attack, 18 of them directly tied to him, spanning years and multiple deputies, plus separate tips to an FBI line describing concerning statements and weapon collecting that were never connected to the local calls for service or to each other³. No individual call, evaluated at the moment it was made, obviously crossed a threshold that would have justified an intervention beyond what was done. The failure the Commission documented was that nobody’s job was to hold all of those individually low-severity contacts in one place and ask what they added up to.

CISA’s physical security guidance frames the same dynamic from the opposite direction, describing what it calls the terrorist attack cycle: surveillance, elicitation, testing or probing of security, and practice runs are named as distinct, sequential phases of hostile planning, each one individually resembling ordinary or marginal activity⁴. A single elicitation attempt looks like a conversation. A single probe of a checkpoint looks like a confused visitor. The cycle is only recognizable as a cycle when the phases are viewed together, which requires someone to have kept and connected the earlier, unremarkable phases rather than letting each be closed on its own.

Insider threat research shows a parallel pattern inside the perimeter. CERT at Carnegie Mellon’s Software Engineering Institute, drawing on its long-running insider threat case database, has documented that malicious insider acts are rarely spontaneous and are typically preceded by precursor behaviors, ranging from policy violations to unusual system or facility access, that are individually minor and often exactly the kind of thing an organization logs, disposes of, and forgets⁵. The guide’s recurring point is that these precursors are detectable in principle well before a damaging act, but only to an organization that is tracking them cumulatively rather than case by case.

The Harder Question: Who Owns the Pattern That No Single Incident Justifies?

None of this is an argument that triage severity should be raised across the board, that every tailgating attempt should trigger a full investigation, or that guards should be second-guessed for closing tickets quickly. Flooding a response queue with low-priority escalations would degrade the system’s ability to handle the incidents that do need immediate action, and it would not by itself solve the aggregation problem. Grading was never the failure point.

The harder question is organizational: if aggregation has to happen outside the response workflow, decoupled from whoever is triaging today’s queue, who is actually responsible for it? Most physical security programs can name who responds to a high-severity incident. Far fewer can name who is tasked with periodically pulling every low-severity record across a set of sites over a rolling window and asking whether the same vehicle, badge number, name, or physical description keeps recurring. If that function exists, is it running continuously, or only after something serious happens and someone finally goes looking for history, at which point the question shifts from prevention to reconstruction. And if a pattern is found, does anyone have the authority to act on an aggregate of minor events when no individual event in it would have justified action alone?

What a Higher Standard for Low-Severity Data Actually Looks Like

Treating low-severity incidents as durable investigative data, rather than as disposed tickets, means the entity in the report, a name, a plate, a badge ID, a physical description, has to persist and be linkable across every other record it touches, independent of how the originating incident was graded or which site or shift it happened on. That is a different design goal than a faster response dashboard. It means the system’s job is not only to route today’s incident to the right responder, but to preserve the context of yesterday’s closed, low-severity incident well enough that it can be found and connected months later, by an analyst who has no reason yet to suspect it matters.

This is where deep discovery across people, entities, incidents, and locations becomes a distinct discipline from incident response, and it is the specific gap an AI-native investigative environment like Hubstream is built to address: not replacing the judgment calls that close a low-severity ticket in ten minutes, but making sure that ticket remains discoverable and linkable so a human analyst can later ask whether it is the third data point in something larger. The interpretation of what a recurring pattern means, whether it is reconnaissance, an insider grievance building, or coincidence, remains a human judgment. What changes is whether the underlying data survives long enough, and in a connected enough form, for that judgment to ever get made.

Questions Worth Asking About Your Own Program

• Does your incident management system let anyone search across closed, low-severity incidents by entity (person, vehicle, badge ID) rather than only by incident number or date?
• Who, specifically, is tasked with periodically reviewing aggregate patterns across low-severity records, and is that a standing responsibility or something that only happens reactively after a serious event?
• When a guard or analyst closes a ticket as low severity, is there any mechanism that resurfaces it automatically if a related entity appears in a future report?
• Are physical security records (badge, visitor, patrol logs) and insider-facing records (HR, IT access, policy violations) siloed in ways that would prevent anyone from connecting a facility-side signal to a personnel-side one?
• If your team found a pattern across a dozen minor incidents with no single triggering event, does anyone have clear authority to escalate on the aggregate alone?
• How far back does your system’s practical search horizon actually go before low-severity data becomes too costly or slow to retrieve?

The Tailgating Attempt Was Never the Problem

The guard who closed that 7:42 a.m. ticket made the right call with the information in front of them. Severity-based triage did exactly what it was built to do that morning: it kept a finite response capacity pointed at what needed it most. What it was never built to do, and what nothing downstream was built to do either, was ask whether that ten-minute encounter belonged next to two others that hadn’t happened yet. The failure, when there is one, is rarely in the closing of the ticket. It is in the fact that closing it was also, quietly, the last time anyone was ever going to look at it again.