How AI is changing the SOC

A Tier 2 analyst opens a case. It already contains a narrative: an account authenticated from an unusual location, touched four internal systems, lateral movement is possible, severity is moderate. The analyst reads it, finds it plausible, and makes a scope decision: which systems to pull logs from, how far back to look and whether to escalate.

Nothing in this sequence is wrong. No rule was broken. But the analyst never saw the raw events the narrative came from. The work of correlating those events — deciding which ones were related, which were noise, what the sequence implied — happened earlier, at intake, and arrived formatted like a finding. The analyst is reading an interpretation and treating it as evidence, not because they are careless, but because the document looks like evidence.

This is the structural change AI assistance introduces in the SOC. The work did not disappear. The decision moved and it moved to a point where less was known, more was asserted, and no record was made of the assertion.

What actually moved

The table below maps five decisions that SOC analysts make routinely. In a conventional workflow, each decision is made by an analyst who built their understanding from raw telemetry where the decision and the evidence-gathering happened together.

AI assistance separates them: the answer arrives before the analyst engages the question.

Decision relocation table

Two patterns run through all five rows.

First, AI assistance presents an answer at the moment the question forms — which is efficient, and also forecloses the question. Second, the cost is not accuracy. A well-calibrated model may rank alerts better than a fatigued analyst at 3 a.m. The cost is that the ordering and the interpretation produce no record of how they were reached, so there is nothing to review when the decision turns out to be wrong.

The tier assumption AI disturbs

SOC operations are typically organized around a tiered analyst structure, where Tier 1 handles initial alert triage and enrichment, Tier 2 conducts deeper investigation and scope determination, and Tier 3 handles complex threat analysis, threat hunting, and decisions requiring the highest level of context.

This structure encodes a specific assumption: information accumulates as work escalates, so a Tier 3 decision is made with more context than a Tier 1 decision. This accumulation is what makes escalation meaningful. A Tier 3 analyst reaching a conclusion about threat actor intent should be working from everything Tier 1 and Tier 2 established — not from a summary of what Tier 1 received.

When a generated narrative is produced at intake and travels upward unchanged, the escalation happens, but the accumulation does not. The Tier 3 analyst is making a decision on the Tier 1 interpretation. The severity assigned at intake becomes an anchor. Anchors resist revision not because analysts are credulous but because the summary reads as settled — it has a structure, a sequence, a conclusion. Revising it upward requires an analyst to assert that the structured account is incomplete, which requires evidence of what it omitted.

That is a harder bar than the pre-AI equivalent, which was simply: look at the raw events yourself.

Within this tiered model, two categories of procedural controls are commonly referenced in SOC governance documentation. Foundation controls define the baseline operating assumptions of the SOC: how tiers are structured, what the escalation criteria are, and what constitutes a valid handoff between analysts. AI-specific controls define how AI-assisted tooling is governed within those tiers: how triage models are validated, how model outputs are documented, and who is accountable for decisions a model proposed.

These are not universal industry standards; they are internal policy designations whose specific numbering varies by organization. The underlying concepts — escalation accountability, model governance, closure criteria — are consistent regardless of what a given SOC calls them.

Those escalation and handoff assumptions map directly to adversary behavior documented in the MITRE ATT&CK framework. When lateral movement (ATT&CK Tactic TA0008) or privilege escalation (TA0004) is in scope, the tiered accumulation of evidence is what allows an analyst to distinguish a single compromised account from a broader campaign. If the Tier 3 analyst is working from a Tier 1 narrative that omitted a relevant process ancestry event — one that might indicate techniques such as process injection (T1055) — the campaign-level assessment will be wrong, and no one will have a record of the gap.

NIST SP 800-61 Revision 3 treats incident response as a continuous risk-management activity rather than a discrete lifecycle, which means the decisions it requires are ongoing governance obligations — not stages to complete and close. (Source: NIST SP 800-61 Rev. 3, https://csrc.nist.gov/pubs/sp/800/61/r3/final)

When the artifact that records a decision is a generated summary rather than an analyst's documented reasoning, that obligation becomes difficult to discharge: the governance record exists, but it does not show who decided what or on what basis.

What stops being visible

A ranked queue has a denominator nobody can inspect. Alerts that a triage model ranks low are mostly not opened, and the ones that are not opened produce no case record and trigger no analyst decision. Because no analyst decided to skip them, there is no decision to review. In a pre-AI backlog, unexamined alerts are at least countable — an analyst can point to the queue and say these were not reached. In a prioritized queue they are still there, sorted below the point where anyone stopped reading, which is a different thing from a backlog and harder to see. The underlying telemetry usually persists and a deliberate query can recover it. What does not exist is a record of the judgment, because no judgment was made.

The practical gap is that a triage model's ordering is rarely instrumented against what it deprioritized. The NIST AI Risk Management Framework treats the measurement of an AI system's performance as an explicit documented activity — not a property to be assumed. (Source: NIST AI Risk Management Framework AI RMF 1.0, https://www.nist.gov/itl/ai-risk-management-framework) Applying that to a SOC triage model means measuring not just whether the top-ranked alerts were true positives, but whether the bottom-ranked alerts contained anything that mattered. That measurement is operationally feasible but infrequently done.

This visibility gap has a direct ATT&CK parallel. Defense evasion techniques — particularly those grouped under the Discovery tactic (TA0007) and sub-techniques involving low-and-slow enumeration — are specifically designed to stay beneath detection thresholds.

A triage model trained on high-confidence, high-severity alert patterns may consistently deprioritize the low-volume reconnaissance activity (T1046, T1087) that precedes a larger intrusion. The model's deprioritization is not wrong by its own metrics; it is wrong relative to what the adversary was doing. That distinction only becomes visible if someone is auditing what the model ranked low.

The point is narrower than a full treatment of triage model governance: an unreviewed model output is a decision record that does not record a decision.

What hasn't changed

Detection still depends on whether the telemetry exists. A model cannot infer an event from data that was never collected. If endpoint telemetry does not include process ancestry, no triage narrative will surface a process injection (T1055) or a living-off-the-land technique such as signed binary proxy execution (T1218) that a collector missed. The generation quality of the summary does not change the coverage gap underneath it.

Scope is still established by evidence, not by narrative quality. A well-constructed case narrative that omits a relevant lateral movement event — such as remote service exploitation (T1021) or pass-the-hash credential use (T1550.002) — does not make the scope accurate. It makes the gap harder to find. Closure still requires that someone verified the things closure criteria require: containment confirmed, persistence mechanisms checked (T1547, T1053), affected accounts reviewed. A summary that reads as thorough is not the same as a check that was thorough.

Accountability has not moved. The organization owns the outcome of a decision an assistant proposed. An analyst who accepted a generated scope recommendation and closed a case that later re-opened is accountable for the closure. The generator is not. This is not a moral argument; it is a functional one — the organization cannot transfer accountability to a model, so the analyst needs what they would need to make the decision independently: the raw events, the detection hypothesis, and the explicit closure criteria. A review that consists of reading the summary the analyst would have written themselves is not a review.

The question to ask your SOC

Take last week's closed cases. For each one, identify which sentences in the case record are observations — things someone directly verified — and which are interpretations — conclusions someone drew. Then ask who produced each one.

If a team cannot consistently separate the two, the SOC's evidence and its summaries have merged. A decision made on a merged record cannot be reviewed afterward, because the record does not distinguish what was checked from what was inferred. The tiered escalation model assumes the distinction is legible at every handoff — that a Tier 2 analyst passing a case to Tier 3 can point to what was verified versus what was inferred, and that the Tier 3 analyst can do the same before closure.

When it is not legible, oversight is still possible — but only if the reviewer has the raw events, the model's inputs, and the closure criteria in front of them, not just the summary. A reviewer reading a summary they could not have produced is present at the review. Whether they are exercising judgment depends on what they can actually see.

Sources