soc operationsctioperational intelligence

The SOC and CTI Feedback Loop: How Threat Intel Earns Its Seat in the SOC

Jason Faulhefer June 23, 2026 7 min read

Share this post

CTI teams complain that the SOC ignores their reports. SOC teams complain that CTI is theoretical. The fix is a small set of feedback rituals.

In most security organizations, the SOC and the CTI team are in the same department, sit on the same floor, and talk to each other almost never about the things that matter. The SOC runs on tickets. The CTI team produces reports. The reports are linked in the wiki and ignored by everyone who has an active queue.

When the relationship works, it produces tighter detections, faster triage, and a measurable reduction in dwell time. When it does not, both sides end up doing parallel work that fails to compound.

The fix is not a new platform or a new role. It is a set of small feedback rituals that each side can sustain.

Why the relationship breaks down by default

The structural problem is that the SOC and CTI optimize for different cycles. The SOC optimizes for the next thirty minutes. Triage this alert. Close this ticket. Hand off this incident. The CTI team optimizes for the next thirty days. Track this actor. Build this profile. Brief leadership next quarter.

When the two cycles meet, the CTI output that lands on the SOC desk is either too abstract to be actionable or too detailed to read on shift. Either way the SOC closes it and moves on. The CTI team, with no signal back, assumes the work is being used and continues producing the same shape of output.

The fix is to introduce one ritual that each side owns and a small shared artifact that lives between the cycles.

The CTI to SOC handoff that survives the shift

The CTI side owes the SOC three things per finished report. Anything beyond is bonus.

A one sentence operational takeaway at the top. Not the executive summary. The operational summary. Example. If you see PowerShell with EncodedCommand from a child of winword.exe and a Net.WebClient call to an external IP, treat as Medium and pivot to user role and host criticality.

A small set of search queries the SOC can paste into the SIEM. Not three pages of YAML. Two or three queries, each targeted at the highest fidelity signal in the report. The SOC analyst should be able to paste, search, and see whether anything matches in two minutes.

A named contact on the CTI team for follow up questions. Not a generic mailbox. A name and a Slack handle. Half the value of the feedback loop is the SOC analyst sending a private message that says we saw three matches, two are legitimate, one is interesting, here is the host.

A report without these three elements is reference material. A report with these three elements is operational intelligence.

The SOC to CTI handoff that survives the report cadence

The SOC side owes the CTI team a different small set of things per shift, not per report.

A short summary of any alert that fired from an intel driven rule. Even if the alert was closed as benign. The CTI team needs to know that the rule is firing, what it is firing on, and what the SOC made of it. A two sentence note in a shared channel is enough.

A short summary of any incident that was not caught by a rule but where intel would have helped. After action format. What happened, what we wished we had known, what we will do differently. This is the most expensive item to produce and the most valuable to receive.

A weekly heat map of which rules fired the most and which ate the most analyst time. The CTI team uses this to prioritize tuning, retirement, and new collection requirements.

Each of these is small. None requires a meeting. All of them require a habit.

The single shared artifact

The two cycles meet on one shared artifact. Call it the active threats board. It is a single page that lists, for each active intelligence priority, the rules in production, the rules in tuning, the rules retired in the last quarter, the open incidents, and the top three things the SOC has learned recently about the priority.

The board is updated weekly. It is the agenda for the standing meeting. It is the source of truth that leadership and operations both read.

It is not a dashboard. It is a wiki page. Tooling does not solve the problem. A wiki page that two teams maintain together does.

The weekly meeting that does the work

One hour, same time every week, with a fixed agenda.

Fifteen minutes on the rules that fired most. The SOC lead walks through volume, precision, and analyst time. The CTI team commits to revisions or retirements.

Fifteen minutes on new intelligence that needs detection. The CTI team brings three items max. The SOC and detection engineering commit to scope for the next sprint.

Fifteen minutes on incidents in the last week. The SOC walks through what happened and what intelligence either helped or would have helped. The CTI team takes notes for the next cycle's collection planning.

Fifteen minutes on the active threats board. Review the page. Update the entries. Confirm that any new priority from leadership is reflected.

No slides. No long presentations. The artifact is the wiki page. The meeting is for the conversation.

Measuring the loop

Three metrics tell you whether the loop is healthy.

Mean time from intelligence finding to deployed detection. Measured in business days. A healthy program runs in single digits for high priority items.

Percentage of alerts that the SOC tags with the intelligence source that motivated the rule. A healthy program is above ninety percent. Untagged alerts mean the link between intelligence and operations is being lost.

Number of incidents per quarter where the after action note credits a piece of intelligence with shortening detection or response time. A healthy program has a small but steady stream of these. Zero in a quarter is a warning sign.

These metrics do not require new instrumentation. They require that the rule has a field for the intel source and that incidents have a field for what helped. Both fields are trivial to add and dramatically change the visibility of the program.

What the CTI team gives up

Building this loop forces the CTI team to give up some of the long form work that gets praise but produces little operational change. The long quarterly report that no one reads. The actor profile that lives on a wiki page no one bookmarks. The conference talk that pulls a senior analyst out of the queue for two weeks.

None of those activities are wrong. They are wrong as the primary output of a team that is also responsible for operational intelligence. The loop above is what earns the team its seat in the SOC. The long form work is what earns the team its seat in the boardroom. Different audiences, different products, different cadences. Pretending both can be served by the same artifact is the most common mistake new CTI programs make.

What the SOC gives up

The SOC has to spend a small amount of time per shift writing two sentence notes back to the CTI team. The notes feel like overhead in the moment. They are the most valuable feedback signal the CTI team will ever receive.

A SOC lead who builds the habit of two sentence notes into the shift turnover script makes it stick. A SOC lead who waits for analysts to do it voluntarily watches it die.

The point

The SOC and CTI relationship works when each side owes the other a small set of artifacts at the cadence the other side runs on. The CTI team owes operational takeaways, paste ready queries, and named contacts on every report. The SOC owes short notes per intel driven alert, after action summaries on incidents, and a weekly heat map. They meet weekly on a shared wiki page. They measure three metrics that tie intelligence to operational outcomes. With those rituals in place, CTI stops being theoretical and the SOC stops being reactive.

Share this post

See it in action

Want intelligence that drives decisions, not noise?