Cyber Threat Intelligence: What It Is, The Types, and How Businesses Actually Use It

Most security teams already have more threat data than they can act on, between firewall logs, endpoint alerts, and vendor feeds nobody has time to read. This guide covers what cyber threat intelligence actually is, the three types, where the data comes from, and how to run it without a dedicated intelligence team. It also covers what CTI costs, how to tell whether it is working, and when buying it beats building it.

What Is Cyber Threat Intelligence?

Cyber threat intelligence is information about cyber threats that has been collected, analysed, and given enough context to inform a decision. It covers who is likely to attack your organisation, what methods they use, what infrastructure they operate from, and what you should do about it.

Gartner defines threat intelligence as evidence-based knowledge, including context, mechanisms, indicators, and action-oriented advice, about an existing or emerging threat to assets. The phrase that matters there is action-oriented. A list of malicious IP addresses is not intelligence. That same list, filtered against the systems you actually run, ranked by relevance to your industry, and delivered to someone who can block them, is.

Most organisations already consume threat intelligence without calling it that. Every time Microsoft Defender blocks a file based on a known malicious hash, or your email gateway quarantines a message from a domain flagged in a phishing campaign, threat intelligence is doing the work in the background.

Threat data vs threat intelligence

Threat data is raw and uncontextualised. Threat intelligence is what you get after someone analyses that data and answers the question "so what?"

The difference is practical, not academic:

• Threat data: the IP address 203.0.113.45 was observed hosting malware.
• Threat intelligence: that IP address is command and control infrastructure used by a ransomware group that has targeted three UK logistics firms in the past month, it is currently active, and your firewall logs show two outbound connection attempts to it yesterday.

The first is a fact. The second tells you to open an investigation. Feeds sell you the first and call it the second, which is why organisations end up with subscriptions they never act on.

What cyber threat intelligence is not

CTI is not a product you buy and switch on. It is not the same as a threat intelligence feed, which is only one input. It is also not a SIEM, though a SIEM is usually where intelligence gets applied.

Three common misreadings:

• CTI is not threat hunting. Hunting is the act of searching your environment for threats. Intelligence is what tells the hunter where to look.
• CTI is not vulnerability management. Vulnerability management looks inward at your weaknesses. Intelligence looks outward at who wants to exploit them, and which ones they are actually exploiting right now.
• CTI is not attribution. Naming the group behind an attack is interesting, and occasionally useful for prediction. It rarely changes what you do in the next hour.

‍

Why Does Cyber Threat Intelligence Matter?

Threat intelligence matters because it tells you which of your thousands of daily alerts deserve attention first. Without it, every alert looks roughly the same, and analysts triage by whatever the tool ranked highest rather than by what is actually dangerous to your business.

The practical effect shows up in three places. It shortens triage, because an alert carrying actor context and campaign history takes less time to judge than a bare detection. It improves prevention, because indicators tied to active campaigns can be blocked before anyone in your organisation clicks anything. And it makes security spending defensible, because "we are seeing this attack pattern against firms our size in our sector" is a stronger argument to a board than "the industry is getting more dangerous."

There is a second reason that gets less attention. Threat intelligence is what makes 24/7 threat monitoring worth paying for. A monitoring service without intelligence is a service that watches your logs and tells you something looks unusual. A monitoring service with intelligence tells you the unusual thing matches infrastructure used in an active ransomware campaign, and here is what to do in the next ten minutes.

Who uses threat intelligence inside an organisation

Threat intelligence is not consumed by one team. Four groups use it, each needing a different format and a different level of technical depth.

The mismatch between these is where most intelligence programs fail. Feeding raw indicators to a business owner produces nothing. Handing a SOC analyst a quarterly geopolitical report during an active investigation produces nothing either. Intelligence only works when the format matches the decision the reader has to make.

For most organisations with 50 to 500 employees, all four of these roles sit with two or three people. The IT manager is also the incident responder. The business owner is also the CISO. That compression is exactly why intelligence usually arrives bundled inside a managed XDR service rather than as a separate subscription, since the provider absorbs the analysis work and delivers only the part that requires a decision.

‍

What Are the 3 Types of Cyber Threat Intelligence?

The three types of cyber threat intelligence are tactical, operational, and strategic. They differ by who consumes them, how long the information stays useful, and how much human analysis goes into producing them.

The split is not a hierarchy. A mature program runs all three, but most organisations start with tactical because it is the cheapest to obtain and the easiest to automate, then add the others as the security function grows.

Tactical threat intelligence

Tactical threat intelligence is technical, indicator-level data that feeds directly into your security tools. It answers the question "what should I block right now?"

This is the layer most people picture when they hear threat intelligence: lists of malicious IP addresses, domain names, URLs, file hashes, and email sender addresses. It is machine-readable, delivered through feeds and APIs, and consumed by firewalls, email gateways, endpoint agents, and SIEM platforms without a human touching it.

The advantage is speed and scale. The limitation is decay. Attackers rotate infrastructure constantly, so an indicator that was accurate on Monday can be dead by Thursday. Threat actors also know their indicators get published, which means the ones you receive for free are often the ones already abandoned. Tactical intelligence is necessary and cheap, but treating it as your whole program is how teams end up with high feed volume and low detection value.

Operational threat intelligence

Operational threat intelligence describes how specific threat actors behave, covering their tactics, techniques, and procedures rather than the individual artefacts they leave behind. It answers "how would this group actually attack us?"

Where tactical intelligence tells you a hash is malicious, operational intelligence tells you the group behind it gains initial access through password spraying against exposed identity portals, establishes persistence via scheduled tasks, and exfiltrates data to cloud storage services before deploying ransomware. That information stays useful far longer, because changing a technique is expensive for an attacker while changing an IP address takes minutes.

This type requires human analysis, which is why it is not free. It is also the layer that produces the most durable detection rules, since behaviour-based detections survive infrastructure rotation. Operational intelligence typically arrives as campaign reports, actor profiles, and technique mappings to MITRE ATT&CK.

Strategic threat intelligence

Strategic threat intelligence is a high-level view of the threat landscape, aimed at people who make budget and risk decisions rather than people who investigate alerts. It answers "where should we be spending, and what are we exposed to over the next year?"

It covers which threat groups are targeting your sector, how attacker economics are shifting, what regulatory change is coming, and how geopolitical events translate into risk for organisations like yours. There are no IP addresses in it. A strategic report might tell a UK manufacturing firm that ransomware groups have moved from encryption toward data theft and extortion, which changes the value of backups relative to data loss prevention controls.

Strategic intelligence is the hardest to produce because it needs analysts who understand both security and the business context around it. It is also the type most often skipped, which is why security budgets frequently get set on vendor marketing rather than on what is actually happening to comparable organisations.

‍

What Data Counts as Threat Intelligence?

Threat intelligence data falls into four main categories: indicators of compromise, tactics and techniques, threat actor profiles, and vulnerability intelligence. Each answers a different question, and each has a different shelf life.

The categories build on each other. Indicators tell you something bad happened. Techniques tell you how. Actor profiles tell you who and why. Vulnerability intelligence tells you which of your own weaknesses those actors are currently exploiting.

Indicators of compromise (IOCs)

An indicator of compromise is a specific, observable artefact that suggests a system has been breached. IOCs are forensic evidence, which means by definition they describe something that has already happened.

Common IOC types:

• Network indicators: malicious IP addresses, domain names, and URLs used for command and control or payload delivery.
• File indicators: file hashes (MD5, SHA-1, SHA-256) identifying known malware samples.
• Email indicators: sender addresses, subject lines, and attachment names tied to phishing campaigns.
• Host indicators: registry keys, file paths, service names, and scheduled tasks created by malware during installation.

IOCs are useful because they are unambiguous and machine-matchable. A hash either matches or it does not. Their weakness is the same as tactical intelligence generally: they are cheap for an attacker to change, so their value drops fast after publication.

Tactics, techniques, and procedures (TTPs)

Tactics, techniques, and procedures describe how an attacker operates rather than what they leave behind. TTPs are the behavioural fingerprint of a threat group.

The three terms are often used together but mean different things:

• Tactics are the attacker's objective at a given stage, such as gaining initial access or escalating privileges.
• Techniques are the methods used to achieve that objective, such as phishing with a malicious link or abusing a valid account.
• Procedures are the specific implementation details, such as which exact tool the group uses to dump credentials.

TTPs are usually mapped to MITRE ATT&CK, a public framework that catalogues adversary behaviour across the full attack lifecycle. Mapping to ATT&CK matters practically, because it gives you a shared vocabulary between your intelligence, your detection rules, and your security tooling. A detection built around a technique catches variants of the same behaviour, while a detection built around a hash catches one file.

IOC vs IOA: what the difference means in practice

An indicator of compromise identifies evidence that an attack has already occurred. An indicator of attack (IOA) identifies behaviour suggesting an attack is happening right now, regardless of which tools the attacker is using.

The difference is timing and durability:

In practice, IOCs catch repeat offenders and IOAs catch novel attacks. A detection strategy built only on IOCs will miss anything the industry has not seen and published yet, which includes most targeted attacks. This is why modern endpoint and extended detection platforms lead with behavioural detection and treat indicator matching as a supporting layer rather than the primary one.

Threat actor profiles and vulnerability intelligence

Threat actor profiles document who is behind attacks, what motivates them, what they target, and how capable they are. Vulnerability intelligence tracks which known weaknesses are actually being exploited in the wild.

Actor profiles typically cover motivation (financial, espionage, disruption, or ideological), preferred targets by sector and region, known TTPs, and historical campaigns. Their value is predictive. If a group known for targeting mid-sized financial firms in your region has shifted to a new initial access technique, you can harden against it before you see it.

Vulnerability intelligence solves a different problem: prioritisation. Tens of thousands of vulnerabilities are published each year, and a small fraction are ever exploited. Vulnerability intelligence tells you which ones have working exploits, which are being used by active groups, and therefore which of your outstanding patches actually carry urgency. Severity scores alone do not tell you this, since a medium-severity flaw under active exploitation is a bigger problem than a critical one nobody has weaponised.

‍

Where Does Threat Intelligence Come From?

Threat intelligence comes from two places: your own environment and the outside world. Most organisations buy the second and ignore the first, which is the wrong way round.

External sources fall into six categories:

• Open-source intelligence (OSINT): publicly available research, vendor blogs, security forums, malware repositories, and social media. Free, broad, and highly variable in quality.
• Commercial feeds: paid, curated indicator streams from security vendors. More reliable and better contextualised than open sources, priced per seat or per volume.
• Information Sharing and Analysis Centres (ISACs): sector-specific member organisations that circulate threat data between peers. Particularly valuable in finance, healthcare, and energy, because the threats are shared and the peers are the same size as you.
• Government advisories: CISA in the United States, the National Cyber Security Centre (NCSC) in the UK, and the UAE Cyber Security Council each publish alerts on active campaigns and exploited vulnerabilities. Free, credible, and usually the fastest confirmation that something is being exploited at scale.
• Dark web and closed-source monitoring: forums and marketplaces where credentials, access, and tooling are traded. Useful mainly for early warning that your own data or credentials are circulating.
• Human intelligence (HUMINT): direct input from researchers, peer security teams, and vendor analysts. Slow, unscalable, and often the highest-value source in the list.

Internal vs external intelligence, and why internal is usually underused

Internal intelligence is threat data generated by your own environment: endpoint telemetry, sign-in logs, email filtering results, firewall traffic, and findings from past incidents. It is the most relevant intelligence any organisation has access to, because it describes attacks aimed at you specifically rather than at the market in general.

External intelligence tells you what is happening to organisations like yours. Internal intelligence tells you what is happening to you. The second is more actionable and costs nothing extra, since you already pay for the tools producing it.

It gets underused for practical reasons rather than ignorance. Internal data is high volume and unstructured. Correlating a suspicious sign-in against an endpoint alert and an email delivery event requires the logs to sit in one place and someone to look at them together. Most teams have the data spread across four consoles and nobody with time to join it up.

That correlation problem is what a SIEM exists to solve, and it is the reason internal telemetry becomes usable intelligence only once it is centralised. Past incidents are the clearest example. An organisation that was phished last quarter knows exactly which pretexts worked on its own staff, which mailboxes were targeted, and which controls failed. That is intelligence no vendor can sell you, and most companies never write it down.

‍

How Are Threat Intelligence Feeds Formatted? (STIX, TAXII, and MISP)

Most threat intelligence is exchanged using two open standards: STIX, which defines how the intelligence is written, and TAXII, which defines how it is transported. MISP is a separate open-source platform that supports both and is widely used for sharing intelligence between organisations.

The distinction is simple. STIX is the language. TAXII is the delivery mechanism. You need both for a feed to reach your tools in a form they can read.

STIX (Structured Threat Information Expression)

STIX is a standardised format for describing threat intelligence in machine-readable form. It gives every piece of intelligence a defined structure, so an indicator produced by one organisation can be understood by another organisation's tooling without translation.

STIX covers more than indicators. It can express threat actors, campaigns, malware families, attack patterns, and the relationships between them. That relationship layer is what makes it useful: STIX can state that a specific domain is associated with a named malware family, which is associated with a campaign, which is attributed to a particular actor. A plain list of domains carries none of that.

The current version is STIX 2.1, which uses JSON. Earlier versions used XML, and some older feeds still do, which occasionally causes compatibility friction.

TAXII (Trusted Automated Exchange of Intelligence Information)

TAXII is the protocol used to transport STIX data between systems. It defines how a client requests intelligence from a server, how collections of intelligence are organised, and how updates are delivered.

In practice, a TAXII server hosts one or more collections, and your security platform connects as a client and pulls from them on a schedule. Access is usually authenticated, which lets providers restrict certain collections to paying subscribers or to members of a specific sharing community.

TAXII matters because it removes the integration work. Without it, every feed would need its own connector. With it, any platform that supports TAXII can consume any TAXII feed by supplying a URL and credentials.

MISP and open-source sharing platforms

MISP, the Malware Information Sharing Platform, is an open-source threat intelligence platform used by sharing communities, government bodies, and internal security teams. It stores, correlates, and distributes intelligence, and supports both STIX and its own native format.

Its main use is community sharing. Members of a MISP community publish events, which are collections of indicators tied to a specific incident or campaign, and other members automatically receive them. Many ISACs and national bodies run MISP instances for exactly this purpose.

For a mid-sized organisation, running your own MISP instance is usually unnecessary. Joining someone else's community is often worthwhile, particularly a sector-specific one, since the intelligence is more relevant than a general commercial feed.

Why format matters when connecting a feed to your SIEM

Format matters because a feed your platform cannot parse delivers no value regardless of how good the intelligence is. Before subscribing to any feed, confirm it publishes in a format your SIEM ingests natively.

Three checks worth running before you commit:

• Supported standard: does the feed publish STIX over TAXII, or a proprietary format requiring a custom connector? Custom connectors mean ongoing maintenance.
• Indicator expiry: does the feed set expiry dates on indicators, or will stale entries accumulate in your platform and generate false positives indefinitely?
• Volume and licensing: high-volume feeds increase ingestion costs on usage-priced platforms, and some licences restrict how long you may retain or share the data.

Microsoft Sentinel supports STIX and TAXII natively, which means most standards-compliant feeds connect through configuration rather than development work. Feeds that only publish in proprietary formats require a custom pipeline, and that engineering cost rarely appears in the subscription price.

‍

What Is the Threat Intelligence Lifecycle?

The threat intelligence lifecycle is the six-stage process that turns raw threat data into intelligence someone can act on: direction, collection, processing, analysis, dissemination, and feedback. It runs as a loop rather than a sequence, because the feedback stage reshapes the requirements set at the start.

The model comes from military and government intelligence practice and is used almost universally across the security industry. Its value for smaller organisations is not the formality, it is the reminder that intelligence starts with a question and ends with a decision. Skipping the first stage is why most programs end up buying feeds nobody reads.

Two stages get skipped most often. Direction disappears because buying a feed feels like progress and defining requirements does not. Feedback disappears because nobody owns it, so unused feeds keep renewing and reports nobody reads keep getting written.

For most mid-sized organisations, stages two through four are the ones that require capability they do not have internally. Collection needs centralised logging, processing needs working connectors, and analysis needs someone who can tell a real match from a coincidence. Direction and feedback, by contrast, cannot be outsourced. Only the business can say what matters and whether the output was useful.

Not sure whether the threat intelligence you already pay for is doing anything? Book a call with CyberQuell to run a free security assessment that maps your current detection coverage, checks which intelligence sources are actually feeding your tools, and identifies where indicators are being collected but never acted on. 

‍

Threat Intelligence vs Threat Hunting vs SIEM vs XDR

These four terms get used interchangeably in vendor marketing, but they describe different things: threat intelligence is information, threat hunting is an activity, and SIEM and XDR are platforms. Intelligence is the input that makes the other three work better.

Threat intelligence is knowledge, not a tool or a task. On its own it changes nothing. Its value depends entirely on whether something downstream consumes it.

Threat hunting is the deliberate search for attackers already inside your environment that your alerts did not catch. Intelligence is what makes hunting efficient, because a hunt needs a hypothesis, and "this actor group targets our sector using this specific persistence technique" is a far better starting point than searching at random.

SIEM collects logs from across your estate and correlates them. It is where threat intelligence gets applied at scale, because matching a feed of indicators against months of your own telemetry is a query problem, and that is what a SIEM is built for.

XDR unifies detection and response across security layers and acts on what it finds. Intelligence sits inside it rather than beside it, informing detections and enabling automated containment without an analyst in the loop.

The practical relationship is layered. Intelligence informs the SIEM and XDR platforms, those platforms surface what matters, and hunting covers what both miss. Choosing between SIEM and XDR is a separate decision with real trade-offs around cost, coverage, and response capability, covered in detail in our breakdown of how SIEM and XDR differ. If you are earlier in that decision and want the underlying mechanics first, how threat detection and response works sets out the fundamentals.

‍

How Threat Intelligence Works in a Microsoft Environment

In a Microsoft environment, threat intelligence arrives from two directions: Microsoft's own intelligence, which is built into Defender and applied automatically, and external feeds, which you connect to Microsoft Sentinel and match against your own telemetry. Most organisations running Microsoft 365 already benefit from the first without configuring anything.

This matters because the intelligence layer most vendors sell separately is, for Microsoft-first organisations, largely already present in tooling you own. The work is connecting and tuning it, not buying it again.

Microsoft Defender Threat Intelligence and threat analytics

Microsoft Defender Threat Intelligence exposes the research behind the signals Defender already acts on. Threat analytics is the reporting surface inside the Defender portal that maps that research against your specific environment.

Threat analytics is the more immediately useful of the two for a lean team, and it is available to any organisation using Defender. It publishes analyst reports on active campaigns and, for each one, tells you how many devices in your tenant are affected, which recommended configurations you have not applied, and which related alerts have already fired. A vendor campaign report tells you a threat exists. Threat analytics tells you whether it has touched you.

Defender Threat Intelligence itself provides deeper investigative data: adversary infrastructure, indicator relationships, and finished intelligence articles through its Intel explorer and Intel profiles surfaces. Microsoft has retired the standalone Defender Threat Intelligence product and folded its capabilities into Microsoft Defender XDR, Microsoft Sentinel, and the Microsoft 365 E5 security licence at no additional cost. A limited free tier remains accessible in the Defender portal, with the fuller investigative datasets available to organisations holding one of those licences. Confirm your own entitlement, since Microsoft's threat intelligence packaging changed materially in 2026.

Ingesting threat intelligence into Microsoft Sentinel

External threat intelligence enters Microsoft Sentinel as threat indicators, which are stored centrally and then matched automatically against the logs Sentinel already collects. There are three main routes in.

• The Threat Intelligence data connector: ingests indicators from any TAXII server publishing STIX data. You supply the server URL, the collection ID, and credentials. This covers most commercial feeds and most ISAC or government sharing communities.
• Upload API and manual entry: for indicators from sources without a TAXII endpoint, or for indicators your own team produces during an incident.
• Microsoft Defender Threat Intelligence connector: brings Microsoft's own indicator set into Sentinel alongside your external feeds.

Once indicators are in, they do nothing until an analytics rule uses them. Sentinel provides built-in matching rules that compare indicators against specific log sources: network logs for malicious IPs and domains, DNS logs for suspicious lookups, email events for known phishing infrastructure, and endpoint telemetry for file hashes. Enabling the right matching rules for the log sources you actually collect is the step teams most often miss, which produces a Sentinel workspace holding thousands of indicators and generating zero intelligence-driven alerts.

Two practical constraints worth planning around. Indicator volume affects ingestion cost on a usage-priced platform, so a high-volume feed carries a running cost beyond its subscription. And indicators without expiry dates accumulate, which degrades match quality over time. Both are configuration decisions rather than product limitations, and both are covered further in our guide to scaling security with Microsoft Sentinel.

Mapping detections to MITRE ATT&CK in Microsoft Sentinel

Microsoft Sentinel includes a built-in MITRE ATT&CK view that shows which techniques your active analytics rules currently detect and which they do not. It turns an abstract coverage question into a visible map.

The practical use is gap analysis. Operational threat intelligence tells you which techniques a relevant threat group uses. The ATT&CK view tells you whether you would detect those techniques today. Where the two do not line up, you have a specific, justifiable case for a new detection rule rather than a general sense that coverage could be better.

Analytics rules carry tactic and technique tags, so incidents arrive already labelled with where in the attack lifecycle they sit. That labelling speeds up triage, because an analyst can see immediately whether an alert represents early reconnaissance or an attacker already attempting privilege escalation.

What this replaces for most mid-market organisations

For most organisations with 50 to 500 employees, Microsoft Sentinel plus Defender removes the need for a standalone threat intelligence platform. The TIP's core functions, aggregating feeds, deduplicating indicators, storing them centrally, and pushing them to enforcement points, are covered natively.

A separate TIP still earns its place in specific cases: organisations running many disparate feeds needing heavy normalisation, teams producing their own finished intelligence for distribution to others, or MSSPs managing intelligence across a large number of client tenants. Below that threshold, a dedicated platform adds licence cost and an integration surface without adding capability you would use.

What it does not replace is the analyst. The tooling can match, store, and alert. Deciding which feeds are worth ingesting, whether a match is meaningful, and what to do about it still requires someone with the time and judgement to look. That gap is why intelligence for most mid-market organisations is delivered through a Microsoft Sentinel SIEM service rather than run in-house.

‍

A Worked Example: How One Threat Indicator Becomes an Action

The following walks a single indicator from arrival to retirement, showing where each part of the intelligence stack does its work.

A commercial feed publishes a domain flagged as credential-harvesting infrastructure tied to an active phishing campaign against professional services firms. The indicator reaches Microsoft Sentinel through the TAXII connector within the hour, carrying a confidence score, a campaign reference, and a 30-day expiry.

Sentinel's matching analytics rules compare it against telemetry already being collected. Two hits surface. DNS logs show a workstation resolved the domain yesterday afternoon. Email logs show eleven messages referencing the same domain reached user mailboxes that morning, three of which were opened.

The resulting incident arrives already enriched. The analyst sees the campaign context from the feed, the tactic and technique tags from the analytics rule, and both the DNS and email evidence in one timeline rather than three consoles. Triage takes minutes rather than an afternoon of correlation.

Response splits across two products. Microsoft Defender for Endpoint isolates the workstation that resolved the domain, pending investigation. Microsoft Defender for Office 365 purges the remaining messages from all mailboxes and blocks the sender infrastructure. Affected users have their sessions revoked and passwords reset.

Three weeks later the attacker rotates infrastructure and the domain goes dormant. The indicator expires on schedule and stops consuming match cycles. What persists is the detection logic built from the technique, which will catch the next domain the same group registers.

The intelligence in that sequence was worth paying for because something consumed it, correlated it against internal data, and triggered a response. The same indicator sitting unmatched in a platform would have produced nothing. Full containment and recovery beyond this point follows the incident response life cycle.

‍

What Are the Main Cyber Threat Intelligence Tools?

Cyber threat intelligence tools fall into five categories: threat intelligence platforms, SIEM systems, intelligence feeds, sandboxing tools, and open-source intelligence tooling. Most organisations use several, and few need all of them.

• Threat intelligence platforms (TIPs): aggregate feeds from multiple sources, deduplicate and normalise indicators, then push them to enforcement points. Most valuable when you are running many disparate feeds or distributing intelligence to others.
• SIEM systems: centralise log data and correlate it, which makes them the place external indicators get matched against your own environment. This is where intelligence becomes detection.
• Threat intelligence feeds: the raw supply. Free from government bodies and open-source communities, paid from commercial vendors, sector-specific from ISACs.
• Sandboxing tools: detonate suspicious files or URLs in an isolated environment to observe behaviour. Produces intelligence rather than consuming it, and answers questions a hash lookup cannot.
• OSINT tooling: searches public sources for exposed credentials, leaked data, lookalike domains, and mentions of your organisation in criminal forums.

For Microsoft-first organisations, the SIEM and much of the TIP function are covered by Microsoft Sentinel, and sandboxing is built into Microsoft Defender for Office 365 through Safe Attachments and Safe Links. What usually needs adding is a relevant feed and, in some sectors, OSINT monitoring for credential exposure.

What to look for when evaluating a threat intelligence tool

The question to ask about any intelligence tool is not what it collects, it is what it changes. A tool that adds indicators without changing a single detection or block has added cost, not capability.

Six criteria worth applying:

• Integration with what you already run: native support for your SIEM and endpoint platform, not a custom connector you will have to maintain.
• Relevance filtering: can it narrow intelligence to your sector, region, and technology stack, or does it deliver everything and leave the filtering to you?
• Indicator hygiene: confidence scoring and expiry dates on every indicator. Feeds without expiry accumulate dead entries and degrade match quality.
• Context depth: does an indicator arrive with campaign and actor context, or as a bare artefact an analyst has to research?
• Total cost including ingestion: on usage-priced platforms, a high-volume feed carries a running cost well beyond its subscription price.
• Proof of action: can the vendor show you indicators that led to a block or an investigation, rather than volume statistics?

The last one filters hardest. Vendors sell on coverage and volume because both are easy to measure. Neither tells you whether the intelligence changed an outcome.

‍

What Are the Challenges of Cyber Threat Intelligence?

The main challenges in cyber threat intelligence are volume, relevance, indicator decay, false positives, attribution difficulty, and staffing. Most of these are problems of filtering rather than access, since intelligence is easy to acquire and hard to use.

• Volume: feeds deliver far more than any team can review. Millions of indicators arrive, a handful matter, and separating the two is the actual work.
• Relevance: intelligence about attacks on cloud service providers means little to a 150-person accounting firm. Most feeds are not filtered to your sector, region, or technology stack, so relevance filtering falls to you.
• Indicator decay: IP addresses and domains rotate within days. An indicator published on Monday may already be dead, which means feed freshness matters more than feed size.
• False positives: low-confidence indicators generate alerts on legitimate traffic. Shared hosting is the classic case, where one malicious site puts an entire IP range under suspicion and every match wastes analyst time.
• Attribution: determining which group is behind an attack is genuinely difficult, and attackers deliberately plant misleading evidence. Attribution is also the least actionable output, so time spent on it usually beats time spent on containment only in retrospect.
• Staffing: every challenge above resolves to a person with time and judgement. That role does not exist in most organisations under 500 employees.

Why most SMB threat intelligence programs stall

Most small and mid-sized threat intelligence programs stall because they start by buying a feed instead of defining a question. Procurement is the easy step, and it feels like progress, so it happens first.

The sequence is predictable. A feed is purchased and connected. Indicators accumulate. Matching rules are either never enabled or enabled broadly, producing either silence or noise. Nobody owns the review, because the person who would has a full workload already. Within two quarters the subscription is renewing automatically and nobody can name a decision it influenced.

The failure is not the tooling. It is the two lifecycle stages that cannot be bought: direction, which says what the intelligence must answer, and feedback, which says whether it did. Both take an hour a quarter and both get skipped, because neither produces anything visible while a feed subscription produces a dashboard.

The practical fix is to start smaller than feels serious. Pick one question that matters, such as whether credentials from your domain are appearing in breach dumps, or whether your sector is being targeted with a technique your controls would not catch. Answer that one properly, act on it, then add the next. A program built this way is defensible in a budget conversation. A feed nobody reads is not.

‍

How to Build a Threat Intelligence Program (Step by Step)

Building a threat intelligence program starts with defining what you need to know, not with selecting a feed. For an organisation of 50 to 500 employees, seven steps get you to something that works and stays working.

1. Define three intelligence requirements. Write down the three questions the program must answer, tied to what would actually damage the business. Ransomware, business email compromise, and credential theft cover most organisations. Three is deliberate, because a longer list means none get answered properly.
2. Inventory what you already collect. List the log sources you have: endpoint, email, identity, firewall, DNS. Intelligence can only be matched against telemetry you actually retain, so this determines which indicator types are worth ingesting at all.
3. Turn on what you already own. For Microsoft-first organisations this means checking threat analytics in the Defender portal and confirming which built-in matching rules are enabled in Sentinel. Teams routinely buy intelligence while leaving included capability switched off.
4. Add one external source, chosen for relevance. Start with free and sector-specific: your national cyber body, plus an ISAC if one exists for your industry. Add a commercial feed only once you can say what the free sources are missing.
5. Enable matching rules that fit your log sources. An indicator type with no corresponding log source produces nothing. Match network indicators to firewall and DNS logs, email indicators to mail telemetry, file hashes to endpoint data.
6. Assign an owner and a review cadence. One named person, one hour a month. They check what matched, what was acted on, and which sources produced only noise. Without this step the program decays quietly.
7. Feed findings back into detections. When intelligence reveals a technique your rules would not catch, build the rule. This is where the program compounds, because technique-based detections outlive the indicators that prompted them.

Steps one, two, and six are the ones that cannot be delegated to a vendor. They require knowing the business.

Build vs buy: when a managed service makes more sense

Building in-house makes sense when you have a dedicated security analyst with time to review intelligence weekly. Buying makes sense when you do not, which describes most organisations in this size range.

Building is worth it when: you have security headcount rather than IT headcount doing security part-time, your sector faces specific threats that generic feeds will not cover well, or regulatory requirements demand documented internal intelligence capability.

Buying is worth it when: your IT team is already at capacity, you need coverage outside business hours, or you have tried a feed subscription before and it went unused. That last signal is the clearest one. A program that stalled once will stall again unless the missing ingredient, analyst time, gets added.

The honest middle position is that direction and feedback stay with you regardless. A provider can collect, process, and analyse. Only you can say what matters and whether the output helped. This is why intelligence usually arrives bundled into managed SOC monitoring rather than sold as a standalone product, since the analysis is worth little without someone acting on it around the clock.

‍

How Do You Measure If Threat Intelligence Is Working?

Threat intelligence is working if it changes what your team does. That means measuring decisions influenced and detections improved, not indicators received.

Six metrics worth tracking, in rough order of how quickly they become useful:

• Percentage of alerts enriched with intelligence context. Of the alerts reaching an analyst, how many arrive carrying actor, campaign, or technique context rather than as bare detections? A rising figure means intelligence is reaching the point of decision.
• Mean time to triage. Track the time from alert to disposition, split between enriched and unenriched alerts. If enriched alerts are not resolving faster, the context being attached is not the context analysts need.
• IOC hit rate against your own telemetry. What proportion of ingested indicators ever match anything in your environment? Low rates are normal, but a source producing zero matches over a quarter is a source to cut.
• False positive rate on intelligence-driven rules. Track separately from your overall false positive rate. High rates usually point to low-confidence indicators or shared infrastructure rather than a broken rule.
• Number of detection rules derived from intelligence. Count rules built because intelligence revealed a technique you could not catch. This is the compounding metric, since technique-based detections keep working after the indicators that prompted them expire.
• Stakeholder report usage. Ask the recipients of your strategic briefings whether anything in the last one changed a decision. If the answer is no twice running, the format or the content is wrong.

The trap: feed volume is not a metric. Indicator counts, feed subscription numbers, and total intelligence ingested measure spend, not value. They rise when you buy more and fall when you cut waste, which means they reward exactly the wrong behaviour. A program that cuts two dead feeds and builds three technique-based detections looks worse on volume and is materially better.

Two practical notes. Set a baseline before changing anything, because triage time and enrichment rates mean nothing without a before figure. And review quarterly rather than monthly, since indicator hit rates are noisy over short windows and a single incident can distort a month badly.

‍

What Does Cyber Threat Intelligence Cost?

Cyber threat intelligence is priced four different ways, and for most organisations the largest cost is not the intelligence itself. It is the analyst time required to use it.

Four things worth knowing before comparing quotes.

1. Free is not a starting position to apologise for. National cyber bodies and sector ISACs publish high-quality, timely intelligence at no cost, often faster than commercial feeds on widely exploited vulnerabilities. Many organisations pay for a commercial subscription while never reading the free advisories that would have told them the same thing.

2. Licence-bundled intelligence is the most commonly overlooked line item. If you already hold Microsoft 365 E5, a meaningful amount of threat intelligence capability is already paid for, since Microsoft folded Defender Threat Intelligence into the E5 security licence, Microsoft Defender XDR, and Microsoft Sentinel at no additional cost in 2026. Threat analytics is available to any Defender user, and the deeper investigative datasets come with those licences rather than a separate subscription. Confirm what your current tier includes before buying anything additional.

3. Ingestion cost is the hidden variable. On usage-priced platforms like Microsoft Sentinel, indicator volume affects your monthly bill independently of the feed subscription. A cheap high-volume feed can cost more in ingestion than an expensive curated one. Ask any vendor for expected daily indicator volume before signing.

4. Analyst time dominates the total. A feed subscription is a fraction of the cost of the person needed to act on it. Any comparison between building and buying that counts only subscription fees against a managed service fee is comparing the wrong numbers. Include the salaried hours, the out-of-hours coverage gap, and the cost of the alerts nobody reviewed.

Published pricing in this market is rare and highly variable by volume, sector, and contract length, so treat any figure you see quoted in isolation with caution. The useful question for a vendor is not what the subscription costs. It is what the total cost is at your expected indicator volume, including ingestion, over a two-year term.

‍

Cyber Threat Intelligence for MSPs and Multi-Tenant Environments

For managed service providers, threat intelligence has an advantage no single organisation has: an indicator confirmed in one client tenant can defend every other client the same day.

That advantage only materialises with the right architecture. Microsoft Sentinel supports multi-workspace management through Azure Lighthouse, which lets a provider query across client tenants from a single console while keeping each client's data in its own workspace. Analytics rules and indicator sets can be deployed consistently across all of them rather than rebuilt tenant by tenant.

The practical pattern is straightforward. A phishing campaign hits one client and the domain is confirmed malicious. That indicator, plus the detection rule built from the underlying technique, propagates to every managed tenant. Client twelve is protected before anyone there sees the email.

Two constraints matter. Client data stays segregated for contractual and regulatory reasons, so what travels between tenants is intelligence, not logs. And indicator quality has to be high, because a false positive deployed across fifty tenants costs fifty times what it costs in one. Providers evaluating this model should read our guide to SOC as a service for MSPs.

‍

Cyber Threat Intelligence and Compliance

No major framework names threat intelligence as a standalone requirement, but several mandate the outcomes intelligence delivers: continuous monitoring, timely vulnerability remediation, and documented incident response capability.

The pattern is consistent across standards. PCI-DSS requires log monitoring and prompt patching of vulnerabilities ranked as critical, which means knowing which flaws are actively exploited. ISO 27001 requires organisations to keep informed about threats relevant to their information assets. SOC 2 auditors look for evidence that monitoring is continuous and that detected issues get triaged. GDPR carries a 72-hour breach notification obligation, and the ability to determine scope quickly depends on the enrichment intelligence provides.

Regionally, NESA (National Electronic Security Authority) in the UAE requires security monitoring and incident management under its IAS controls, alongside ISR (Information Security Regulation) for Dubai government entities and ADHICS (Abu Dhabi Healthcare Information and Cyber Security Standard) for Abu Dhabi healthcare providers. In the UK, Cyber Essentials focuses on baseline technical controls rather than intelligence specifically, though its patching requirements benefit from knowing what is exploited in the wild.

The practical takeaway is that intelligence rarely appears as its own audit line item. It shows up as the reason your monitoring caught something, your patching was prioritised correctly, and your breach timeline was reconstructed inside the notification window.

‍

Final Thoughts

Threat intelligence is not a product decision. It is a question about whether anything in your environment changes when new information arrives.

Most organisations already have the raw material. Endpoint telemetry, sign-in logs, email filtering results, and whatever your last incident taught you are more relevant than anything a vendor can sell, and they are already paid for. Microsoft-first organisations sit on more of it than most, since Defender and Sentinel carry intelligence capability that frequently goes switched off rather than unavailable.

What is usually missing is not data. It is the two things that cannot be bought: someone deciding what the intelligence needs to answer, and someone checking afterwards whether it did. Skip those and you get a renewing subscription and a dashboard nobody opens. Get them right and a modest program outperforms an expensive one.

Book a call with CyberQuell and we will show you what threat intelligence your current Microsoft licences already include, which feeds are worth paying for in your sector, and what your team would need to do to act on them. If the answer is that nobody has the time, that is what our managed detection and response service covers: intelligence matched against your telemetry in Microsoft Sentinel, reviewed by analysts, around the clock.