The first article in this series, The Attack Loop Is Compressing. The SOC Is Not, has a simple argument: AI does not need to make every attacker brilliant. It only needs to shorten the time between a failed attempt and the next useful action. But faster offense is only half of the problem. The harder question is why the defensive loop cannot tighten at the same rate.
Most SOCs do not fail because nobody knows what to do.
They fail because what one person knows does not survive the next workflow.
Threat intelligence knows why a technique matters. Threat hunting knows where it may be visible. Detection engineering knows what assumptions sit behind the rule. The investigator knows which evidence changed the verdict. The response owner knows which actions could break the business.
Then we compress all of that into an indicator, an alert, a ticket, or a task.
The work moves forward. The meaning does not.
That is the lossy handshake.
The SOC Is Not A Straight Line
The common operating model shows five stages:
- Threat intelligence identifies what matters outside the organization.
- Threat hunting asks whether that behavior exists here.
- Detection engineering turns knowledge into repeatable coverage.
- Investigation determines what happened, how far it reached, and what decision is needed.
- Remediation turns that decision into action.
This is a useful lens. It is not a universal org chart.
In a small SOC, one person may perform several of these functions. In a large enterprise, they may be distributed across the SOC, detection engineering, identity, endpoint, cloud, application, platform, and business teams. An MDR provider may own the investigation but not have authority to contain. A security engineer may own the playbook but never see the original alert.
The workflow is not linear either. Investigations should create new hunts. Hunts should expose telemetry gaps. Remediation should reveal missing ownership. False positives should change detection logic. Each stage should alter the next pass through the loop.
That is how a learning system behaves.
Most SOCs have the boxes. What they lack is durable state between them.
What Actually Gets Lost
We use the word context so broadly that it has almost stopped meaning anything. A few enrichment fields beside an alert are not context.
The handshake needs to preserve at least five things:
- Entity identity: Which user, device, workload, application, tenant, or business process are we actually discussing?
- Evidence and provenance: What supports the conclusion, where did it come from, and when was it observed?
- Hypothesis and confidence: What do we think happened, what alternatives remain, and how certain are we?
- Telemetry sufficiency: What could we verify, what could we not see, and which missing source limits the conclusion?
- Decision ownership and constraints: Who can act, what approval is required, and what operational risk comes with the action?
Lose entity identity and two teams investigate the same user under different names.
Lose provenance and nobody can defend the conclusion.
Lose the hypothesis and the next analyst starts from zero.
Lose telemetry sufficiency and missing evidence gets mistaken for evidence of absence.
Lose decision ownership and a correct recommendation sits untouched in a queue.
The alert survived. The decision state did not.
One Incident, Five Different Stories
Consider a straightforward identity incident.
A finance employee signs in from an unfamiliar hosting provider. MFA is satisfied. Ten minutes later, a new mailbox forwarding rule appears. Then the account downloads several files from a finance SharePoint site.
No single event proves compromise. Together, they deserve attention.
Threat Intelligence
The intelligence team has been tracking adversary-in-the-middle phishing that steals authenticated sessions. They know MFA success does not rule it out. They also know these campaigns commonly create mailbox rules and access cloud documents soon after initial access.
The intelligence is useful, but its output becomes a short advisory with a few indicators and technique IDs.
What gets lost? The behavioral sequence and the conditions under which the intelligence should matter locally.
Threat Hunting
The hunter translates the advisory into questions. Do we have sign-ins from hosting providers followed by new inbox rules? Can we correlate cloud sessions with managed-device state? Do we retain enough mailbox audit data to establish sequence?
The hunter discovers that sign-in and mailbox telemetry are available, but device compliance is only present for part of the environment. SharePoint audit data arrives several hours late.
The hunt finds two suspicious accounts and a telemetry limitation.
What moves forward? A list of accounts.
What gets lost? The coverage caveat and the reason those accounts were selected.
Detection Engineering
The detection engineer builds logic around the sequence. An unfamiliar network alone is noisy. MFA success alone is expected. A new forwarding rule alone may be legitimate. Combined within a short window, they become meaningful.
The engineer also knows the detection cannot reliably evaluate device state for every user and that SharePoint activity may arrive late.
The rule ships with a severity and a description.
What gets lost? Its assumptions, blind spots, expected false-positive patterns, and the evidence needed to increase confidence.
Investigation
The alert reaches an analyst during a busy shift. The alert shows the sign-in and mailbox rule, but not the reasoning that connected them. The analyst opens the identity console, the email security portal, the SIEM, the asset inventory, and the ticketing system.
Eventually, the analyst confirms the user has never used that hosting provider, the session came from an unmanaged device, the forwarding address is external, and the SharePoint downloads are unusual for the account.
The analyst concludes that the account is likely compromised.
What gets recorded? “True positive. Recommend disabling user and revoking sessions.”
What gets lost? The evidence chain, the confidence level, the unverified endpoints, the delayed SharePoint telemetry, and the distinction between urgent containment and full remediation.
Remediation
The identity team receives a task to disable the account.
They know something the SOC does not: the user is processing payroll, and disabling the account will interrupt a time-sensitive business process. That does not mean the account should remain active or that finance gets to veto containment. It means the response must include business continuity.
The right response may be to revoke active sessions, remove the forwarding rule, suspend the account under incident policy, move payroll processing to a backup owner, and restore access only after credentials, MFA, and a managed device have been validated.
The SOC had the threat context. The identity team had the operational context. Neither had the complete decision state.
Everyone did their job.
The system still made them reconstruct the incident at every boundary.
The Unicorn Analyst Is A Compression Algorithm
When organizations recognize this problem, they often respond with a job description.
They look for someone who understands identity, endpoint, cloud, email, network, malware, threat intelligence, detection engineering, KQL, SPL, incident command, business risk, and executive communication.
Then they ask that person to work the alert queue.
The mythical unicorn analyst is not a talent strategy. It is a workaround for missing system state.
The senior analyst succeeds because they carry an internal map of the environment. They know which log source is unreliable, which service account cannot be disabled, which rule has a reputation for noise, and which application owner will answer at 2 a.m.
In other words, the organization stores its operating model in a person’s memory.
That can work for a while. It does not scale, and it does not survive turnover.
Burnout is not only a workload problem. It is what happens when people repeatedly rebuild context that the system should have preserved.
Integration Is Not The Same As Continuity
Vendors often answer this with another connector.
Connectors move data. They do not automatically preserve meaning.
A SIEM can ingest the identity alert. A SOAR platform can create a ticket. An API can send a containment request. All three integrations may work exactly as designed while the hypothesis, confidence, coverage gap, and business constraint disappear.
The issue is not whether Tool A can call Tool B.
The issue is whether the next function can see what the previous function knew, what it assumed, what it could not verify, and why it made the decision it made.
That is continuity.
The Feedback Loop Is Usually The First Casualty
The most expensive loss often happens after the incident is closed.
Suppose the finance sign-in turns out to be legitimate. The employee was using a new travel connection, and the forwarding rule was approved. That finding should not simply become “false positive.”
Detection engineering needs to know which evidence overturned the original hypothesis. Threat hunting needs to know whether the behavior appears elsewhere. Telemetry owners need to know that device coverage was incomplete. The next investigation needs to inherit the corrected understanding.
Instead, the analyst selects a closure reason and moves on.
The organization records the verdict but discards the lesson.
That is how noisy detections stay noisy. It is how the same blind spot gets rediscovered. It is how senior analysts become human lookup tables for institutional memory.
Measure The Reconstruction Tax
Mean time to acknowledge and mean time to remediate tell us how quickly work moves. They do not tell us how much work was repeated.
SOC leaders should also ask:
- How much investigation time is spent locating or revalidating context that another function already had?
- How often does a response owner request information that exists elsewhere in the case?
- How long does it take an analyst correction to reach the detection owner?
- How many false positives repeat for the same known reason?
- How often is a conclusion limited by missing telemetry, and is that limitation visible in the final decision?
- How many containment actions wait because the owner or approval path was unknown?
These are measures of coordination debt.
You cannot tune your way out of coordination debt. You have to preserve the state that tuning, investigation, and response depend on.
The Handshake Is The Architecture
Current incident-response guidance increasingly reflects this reality. NIST SP 800-61r3 treats incident response as an integrated part of cybersecurity risk management across organizational operations. Microsoft’s SecOps operating-model guidance explicitly depends on engineering, operations, application, architecture, and business teams. FIRST’s CSIRT Services Framework separates analysis, coordination, mitigation, recovery, and decision responsibilities while emphasizing the information flow between them.
The organizational labels vary. The underlying requirement does not.
A modern SOC must carry decision state across tools, functions, and owners without requiring each person to recreate it.
That does not mean putting everyone in one console. It does not mean pretending AI can make every decision. It means building shared operational memory in which evidence, hypotheses, uncertainty, coverage, ownership, and outcomes remain connected.
The lossy handshake is not a collaboration problem.
It is an architectural one.
In the final article, I will move from diagnosis to architecture. We will define what the SOC needs to remember, how bounded agents should work from that shared state, how the system should represent uncertainty, and where human authority must remain.
The goal is not autonomous security. It is a defensive loop that stops forgetting.
Frequently Asked Questions
What is the lossy handshake in a SOC?
It is the loss that happens when work changes hands between SOC functions. Threat intelligence, threat hunting, detection engineering, investigation, and remediation each know something the next function needs, but that knowledge gets compressed into an indicator, an alert, a ticket, or a task. The work moves forward and the meaning does not.
What context has to survive a handoff between SOC functions?
At least five things: entity identity, evidence and provenance, hypothesis and confidence, telemetry sufficiency, and decision ownership and constraints. Lose entity identity and two teams investigate the same user under different names. Lose telemetry sufficiency and missing evidence gets mistaken for evidence of absence. Lose decision ownership and a correct recommendation sits untouched in a queue.
Will hiring a senior “unicorn” analyst solve it?
No. The mythical unicorn analyst is a workaround for missing system state, not a talent strategy. Senior analysts succeed because they carry an internal map of the environment, which means the organization is storing its operating model in a person’s memory. That does not scale and it does not survive turnover.
Do more integrations fix the problem?
Connectors move data, but they do not automatically preserve meaning. A SIEM can ingest the alert, a SOAR platform can create a ticket, and an API can send a containment request while the hypothesis, confidence, coverage gap, and business constraint all disappear. The question is not whether Tool A can call Tool B, it is whether the next function can see what the previous one knew, assumed, and could not verify.
What should SOC leaders measure instead of MTTA and MTTR alone?
The reconstruction tax. Ask how much investigation time is spent revalidating context another function already had, how often a response owner requests information that already exists in the case, how long an analyst correction takes to reach the detection owner, how many false positives repeat for the same known reason, and how many containment actions wait because the owner or approval path was unknown. These are measures of coordination debt.
About Jonathan Waknin, Director of Solution Architects | CISO, Conifers
Jonathan Waknin is a cybersecurity leader with 15 years of experience building and scaling global SOCs. Before Conifers.ai, he led high-performing security teams and services supporting top enterprise customers in the MDR and MSSP space. Now, as Director of Solutions Architects, he brings that operational expertise to innovation—combining SIEM/EDR integrations with AI-driven automation. Known for a results-driven approach, he focuses on real investigations, measurable outcomes, and customer-first operations. His vision highlights how SOCs can move from noisy alert queues to decision-driven systems where AI amplifies human judgment and restores meaning to the analyst’s role.