Per-Customer Threat Intelligence vs Generic IOC Reports.
Picture two companies that both receive the same threat feed on the same morning. One is a regional bank that runs its own payment systems. The other is a logistics firm whose biggest exposure sits in a handful of supplier portals. The feed lands a fresh list of indicators in both inboxes: a few hundred IP addresses, some file hashes, a clutch of domains. For the bank, three of those domains map directly onto a campaign hitting financial services in its region. For the logistics firm, those same three domains are noise, and the one indicator that actually matters to it is buried somewhere in the other few hundred lines, unmarked.
That gap, between an indicator and a piece of intelligence, is the whole subject of this post. An indicator is an observable: a hash, a domain, an IP. Intelligence is that observable plus the context that tells a specific organisation whether it matters, why, and what to do about it. The same line in a feed can be the most important thing one customer sees all week and completely irrelevant to the next. So when an MSSP hands a customer a context-free list, or forwards a feed that everyone on the platform receives unchanged, it is passing along the raw material of intelligence and asking the customer to do the analysis themselves. Per-customer threat intelligence is what you do to that raw material before it reaches anyone.
An indicator is not intelligence
The CTI lifecycle has a step that tends to get skipped when feeds move fast: analysis. Collection gathers the observables, processing tidies them up, and then, ideally, a human or a system assesses what they mean for a particular reader before any of it gets disseminated. A generic IOC report tends to compress that lifecycle down to collection and dissemination, with the assessment left as an exercise for whoever opens the file. The indicators are real and often accurate. What they lack is the “so what” and the “now what.”
It is easy to understand why generic feeds look the way they do. Producing them at scale is genuinely hard, and a shared feed has to be readable by every possible subscriber, which means it can be tailored to none of them. The economics push towards one artefact for everyone. That is a reasonable trade-off for a feed publisher whose product is breadth. It becomes a problem only at the last mile, when a service provider forwards that same one-size artefact to a customer who has a specific set of assets, a specific supplier list, and a specific reason to care about some lines and ignore the rest.
Three things turn an indicator into intelligence for a given reader:
- Relevance. Does this observable connect to something the organisation actually has, uses, or depends on?
- Context.What is the indicator part of? A known campaign, a particular actor's infrastructure, a supply-chain compromise that touches one of the organisation's vendors?
- Direction. What is the reader supposed to do with it, and where does it need to go: a SIEM rule, a firewall block, a note to the supplier owner?
Strip those three out and you are left with data. Data has a place, but it is not the thing a customer is paying a security provider to deliver.
Why one customer's signal is another customer's noise
Relevance is not a property of an indicator. It is a relationship between the indicator and a specific organisation. A domain used in a phishing kit aimed at a payroll platform matters enormously to the company that runs payroll on that platform, and not at all to the company next door that does not. A vulnerability in a particular VPN appliance is urgent for the firms that expose it to the internet and academic for everyone else. Even within a single sector, two organisations can have completely different exposure: same industry, different suppliers, different technology stack, different geography, different regulatory pressure.
Two customers in the same sector, reading the same event, should get two different reads. If they get the same one, the tailoring is happening in the marketing copy, not in the analysis.
This is why a shared feed underdelivers at the customer's desk even when the feed itself is excellent. Volume is part of it; a busy SOC will not hand-assess several hundred indicators a day against its own estate. But the deeper issue is that the work of deciding “does this matter to us” has been pushed downstream to the people with the least time to do it. The provider had the best opportunity to answer that question, because the provider is the one running the analysis at scale. When the answer arrives un-answered, the customer either over-reacts to noise or, more often, lets the whole thing slide because triaging it is more work than ignoring it.
What per-customer threat intelligence actually means
Per-customer, or per-client, threat intelligence flips the order of operations. Instead of producing one artefact and broadcasting it, you decide what each customer needs to know first, and then assess every incoming event against that. The mechanism that makes this tractable is a per-organisation set of Intelligence Requirements: the standing questions a given customer needs answered on an ongoing basis. Priority Intelligence Requirements are simply these requirements with prioritisation applied; the prioritisation is handled for you rather than left as a manual chore.
Those requirements are derived from the things that make a customer specific: their asset inventory, their suppliers and the wider supply chain they depend on, their sector, and their geography. They are not a questionnaire you fill in once and forget. They are self-maintaining, updating as the customer's exposure and the threat picture change, so the definition of “relevant” stays current without someone rewriting it every quarter.
At Liberty91, each customer gets its own set of Intelligence Requirements and its own dedicated AI agent stack. Across hundreds of sources read in real time, every event is assessed against every relevant requirement for that specific customer and scored for how much it matters to them. The bank and the logistics firm from the opening do not share a verdict. The same domain that lights up against the bank's payment-rails requirements is read against the logistics firm's supplier requirements and, finding nothing, is set aside for them. That per-reader assessment is the part a generic feed structurally cannot do, because at the moment it is published it does not yet know who is reading it.
From a verdict to something a SOC can use
Deciding relevance is half the job. The other half is delivering the result in a form the customer's team and tooling can act on without re-doing the work. A per-customer approach should produce more than a yes-or-no on each indicator; it should produce the working detection content alongside it.
In practice that means a few different outputs, matched to who is going to consume them:
- Written reports for the humans, with the assessment up front: what happened, whether it touches this customer, and what to do.
- Enriched and scored IOC lists, where each indicator carries the context and the relevance judgement, not just the raw value.
- Detection content ready to deploy: Sigma rules for log-based detection and STIX 2.1 bundles for systems that speak that standard.
Those outputs then need to land where the work happens. Per-customer intelligence is only as good as its delivery, so it should flow directly into a customer's SIEM, SOAR, firewall, or threat intelligence platform, and into the automated and AI-driven security agents that increasingly sit in front of those tools. Leaked-credential and supply-chain monitoring feed the same loop, because a credential exposed for one customer or a compromise at one customer's supplier is exactly the kind of event that is critical for them and irrelevant for the customer sitting beside them on the same platform.
How an MSSP delivers this without building a CTI team per customer
For a managed security provider, the obvious objection to per-customer intelligence is cost. Tailoring intelligence to every account in your customer base sounds like hiring an analyst per customer, which does not scale. The point of doing the assessment in the platform is that you get real intel at machine speed without a team to build behind each account. The per-customer Intelligence Requirements and the dedicated agent stack do the relevance work; the provider keeps oversight of the output.
Delivery across many accounts is its own problem, and it is where a lot of good intelligence ends up wasted. Our Mailroomhandles multi-tenant dispatch: each customer's Morning Report and Alerts are routed to the right account, with an auditable per-customer Sent log so a provider can show exactly what went to whom and when. It is white-label end to end, so the sender and reply-to address, the email templates, and the report PDFs all carry the provider's brand rather than ours. The customer experiences intelligence tailored to them, delivered by their provider; the provider does not stand up a bespoke pipeline per account to make that happen. If you want the broader picture of how this fits a managed-service model, our MSSP solution and threat intelligence as a service pages walk through it.
Generic feeds still belong in the mix
None of this means a shared feed is worthless. Raw feeds, commercial and open-source, are good and necessary input. They are the collection layer, the wide net that catches observables before anyone knows which of them will matter to which customer. The argument here is not feeds versus intelligence; it is about what happens to a feed between the moment it arrives and the moment it reaches a customer.
The distinction worth holding onto is simple. A generic IOC report is the raw material. Per-customer threat intelligence is the assessed, scored, delivered result of running that raw material through one specific organisation's requirements. If a customer is doing the relevance work themselves, after the report lands, the analysis step has been moved onto the desk least able to absorb it. Doing that step for them, before delivery, is the difference between sending data and sending intelligence.
Where Liberty91 fits
Liberty91 was built around the idea that relevance should be decided before delivery, per customer, not after delivery, by the customer. Each organisation gets its own self-maintaining Intelligence Requirements and a dedicated agent stack that reads hundreds of sources in real time and assesses every event against what that specific customer cares about. The result is surfaced, prioritised, and drafted in real time as written reports, enriched and scored IOCs, Sigma rules, and STIX 2.1 bundles, then delivered into the customer's existing tooling and, for providers, dispatched per tenant through a white-label Mailroom with a full audit trail.
If you run security for a portfolio of customers and want to see what per-customer intelligence looks like against your own accounts, our MSSP solution is the place to start, and the Intelligence Requirements page explains the engine underneath it. Have a look, and tell us which of your customers would read the same event differently.
