An intelligence source is anything that answers a question you have asked: open-source material, paid vendor feeds, community sharing, or your own internal telemetry. The distinction that matters is between a source, which supplies analysis and context, and a feed, which supplies raw data. Sources are chosen against requirements, blended for corroboration, and reviewed for whether they are still earning their place.
Read first: The intelligence cycle (collection is a phase of it)
Sources are the backbone of threat analysis, and the mistake most organisations make with them is treating acquisition as the hard part. Buying a feed is easy. Knowing which question it answers, whether anything else confirms what it says, and whether anyone actually reads it, is the work.
This is the distinction to internalise first. An intelligence source provides analysis, context and something you can act on. A feed pushes raw data or news.
Both have uses, but selecting sources that merely push volume overloads analysts and dilutes focus, and the cost is paid in attention rather than in budget. A curated, analysed source saves an analyst time; a firehose transfers the analytical burden onto them and calls it coverage.
Three requirements sit under every source, and they are not interchangeable. Accuracy means what it says is true. Reliability means it is consistently true rather than occasionally brilliant. Timeliness means it arrives while the information still changes a decision.
A source failing any one of them fails, and the failure modes are different: an inaccurate source misleads, an unreliable one cannot be planned around, and a late one produces history. Prioritise sources with a track record on all three rather than a strong showing on one.
Open-source intelligence is consistently undervalued inside organisations, usually because it is free and therefore assumed to be thin. It is neither. OSINT covers everything from threat actor chatter to publicly available technical material, it is frequently more timely than paid alternatives, and it answers questions proprietary sources cannot.
Two clarifications worth making to stakeholders, because both surprise people. Material on the dark web is open source. So is GitHub. The category is defined by whether the material is publicly obtainable, not by whether it is easy to reach or respectable to mention in a board paper.
Part of the intelligence function's job is educating the organisation on this, because a team that has to justify OSINT every budget cycle will eventually stop using it properly.
Paid vendor intelligence comes with service level agreements and contractual obligations to meet a standard. That reliability is genuinely valuable, and in some operations it is essential.
Community-shared intelligence, through sector sharing groups and analysis centres, is often firsthand and closer to the ground than anything commercially available. What it lacks is any contractual guarantee: it arrives when a peer chooses to share it, in whatever shape they chose.
These are complements rather than substitutes, and confusing their properties causes real problems. Treating community material as a dependable supply line means planning around something nobody promised you, and treating paid feeds as sufficient means missing what your peers are seeing right now.
Relying on one source is limiting and risky in equal measure. Using several allows cross-verification, and multisource corroboration is what turns an assertion into an assessment you would put your name to.
This is also the practical defence against being wrong in public. A claim carried by one source and repeated by you is your claim now, and the cost of that lands on the function's credibility rather than on the source's.
Intelligence is only useful if the team can actually reach it. Friction in access, whether through awkward portals, inconsistent formats or authentication that breaks weekly, quietly reduces what gets read.
Delivery frequency needs to match operational tempo. A source that reports weekly cannot serve a question that needs answering daily, and a team operating across time zones should favour sources that deliver continuously rather than in one overnight batch that lands when nobody is awake.
Sources should be mapped to the priority intelligence requirements they serve. That mapping does three things at once: it shows which requirements have no source behind them, which sources serve no requirement, and where the overlap is thick enough that something could be cut.
Review has to be periodic and real. Assess each source for accuracy, timeliness and reliability against what your team currently needs, not against what it needed when the contract was signed. Needs evolve; sources should be allowed to fail that test and be dropped.
Every piece of incoming intelligence should be consumed, assigned for action, or deliberately dismissed within a set period each day. The important word is deliberately. Ignoring intelligence through oversight or absent routine is not a neutral outcome; it is how something that mattered goes unread while the team is busy.
A structured daily workflow for this is unglamorous and does more for capability than most tooling decisions.
Source selection carries bias, usually invisibly. A set weighted toward particular vendors, regions or types of intelligence produces a skewed picture that feels complete from the inside. A deliberately diverse set, without favouritism toward a familiar supplier or a comfortable region, supports a more objective view and reduces the risk of misinformation propagating into finished product.
Internal control data, logs, alerts, detections from the tools you already run, is a genuine intelligence source and one of the few nobody else has. Correlating it with external intelligence is what lets you say whether something reported globally is present in your environment, which is usually the question a stakeholder is actually asking.
Two disciplines make this work. Do not become the data owner. Access is not ownership, and taking on custody of high-volume control data brings management burden that will consume the function. Agree access and usage with the control owner and stay in the analysis role.
And get involved at procurement. When a new control is being bought, the intelligence function's requirements should be on the list before the contract is signed. Retrofitting access afterwards is expensive and sometimes impossible.
Internal sources map onto the vectors much as external ones do: email security for phishing, endpoint detection for malware, vulnerability management for hacking, network and provider relationships for denial of service, data loss prevention for insider risk. The mapping is worth doing explicitly, because it shows which vector you are blind to internally.
Conundrum runs open-source collection continuously against your requirements, across the vectors, so OSINT is treated as the primary resource this chapter argues it should be rather than as something a spare analyst does on a Friday.
The part worth drawing attention to is source health. Sources break, move and go quiet, and a collection programme that cannot tell you which of its sources stopped reporting is asserting coverage it does not have. Collection health is tracked, and a source that fails repeatedly is flagged rather than silently dropped, which is the mechanism behind the claim that you can see when intelligence stops arriving.
