Your Threat Intelligence Team Is Collecting Data and Calling It Intelligence
The Intelligence Tradecraft Your CTI Team Was Never Taught - What a CISO needs
By Dan Tinsley, Founder of DTN Advisory
31 March 2026 - Long form article based and updated from a prior publication on in 2015
Picture this. You are the CISO. It is 0745H on a Monday morning. You sit down with your coffee. You open your inbox. There are 147 emails. 12 of them are “threat intelligence.” One is a dashboard export with 400 rows of red. Another is a ten page report on an APT group you have never heard of called FrizzyZebra. A third is marketing from vendors telling you that ransomware is up 47% this quarter and AI will save you, while a board advisor asks if you are impacted by a dangerous cyber attack Bleeping Computer reported on in a completely different industry.
You closed the laptop. You drank the cold coffee. You learnt nothing.
This is the state of threat intelligence in most organisations. It is not intelligence. It is noise.
Actual intelligence, done properly, tells you exactly what to do next. It tells you where to spend your limited budget. Which of your 400 open vulnerabilities actually matters. What your adversaries are doing right now, not what they did six months ago, against a different industry.
The intelligence discipline exists. The frameworks are proven. They have been used by intelligence services for decades. They work in every domain, not just national security. Cyber threat intelligence, SIGINT, fraud, HUMINT, risk management. The lifecycle remains the same. The tradecraft remains the same. And most CTI teams have never been taught it and the CISO is unaware.
TLDR:
Collecting information and producing intelligence are fundamentally different activities. Most organisations are doing the first and calling it the second.
93% of organisations have some form of intel capability. Only 55% measure whether it actually works.
The quality of your intelligence is determined by the quality of your requirements. Vague PIRs produce expensive noise.
Not all sources are equal. Rate them. The NATO Admiralty System has been doing this for decades. If you would not trust the source in a conversation you should not trust it in a report.
Intelligence should reach three audiences: strategic for the decision makers, operational for resilience leaders (TechxCyberxRisk), tactical for the SOC/NOC/Fraud. Most teams only deliver tactical.
Cyber does not exist in isolation. Fuse cyber, fraud, risk and engineering together. The patterns you miss in silos become obvious when you combine them.
Fix the basics before you buy the fancy stuff. If 90% of your fundamentals are broken, no amount of threat intelligence will save you.
Decision velocity: the speed at which you turn reliable intelligence into action. That is the real objective. Everything else in this article shows you how to get there.
Start With Why
Simon Sinek said it better than anyone: start with why. Before you build a CTI team, before you buy a single feed, before you hire your first analyst, answer this question: why do you need threat intelligence?
Not “because everyone else has it.” Not “because the board or regulator asked for it.” Not “because a vendor showed us a very impressive dashboard.” Why?
You need threat intelligence because it tells you exactly where to spend your budget, which vulnerabilities actually matter and what your adversaries are doing right now. It turns guesswork into assessed judgement. Reaction into anticipation. Scattered spending into deliberate investment.
That is the why. Everything else follows from it.
If your CTI programme cannot articulate its own purpose in one sentence that a board member would understand, you have a programme looking for a reason to exist.
That never ends well.
The CISO’s Red Line Problem
If you have ever been riding the Singapore MRT during rush hour, you know the feeling. Everyone is crammed in. Some uncle is watching TikTok on speakerphone. A group of teenagers is laughing about something. The announcements are playing overhead. Someone is coughing directly into the back of your neck. Now imagine everyone on that train started talking directly at you.
That is what it feels like to be a CISO receiving “threat intelligence.” Everyone is shouting at you. Vendors. Analysts. Dashboards. News feeds. Peer networks. Signal groups. Government advisories. Every single one of them is telling you something is urgent. None of them is telling you what to actually do about it.
Intelligence does not add to the noise. Intelligence cuts through it. Real intelligence answers a question you actually need answered. It tells you what to prioritise. It tells you what to ignore. It gives you the confidence to walk into a board meeting and say, “Here is what matters to us specifically, here is why, and here is what we are doing about it.”
If your threat intelligence programme is not doing that, you do not have a threat intelligence programme. You have a very expensive subscription to anxiety.
Every CISO in their first hundred days knows this feeling. Everyone in the organisation has an opinion about what is urgent. The previous incumbent left a backlog the size of a small novel. The board wants reassurance. The security team wants budget. The vendors are circling like birds at a hawker centre. And somewhere in all of that noise, the actual threats are sitting there, patiently waiting to be noticed.
Information Is Not Intelligence
This is the single most important thing I will say in this article (and I have a t-shirt with this slogan on). Collecting information and producing intelligence are fundamentally different activities. Most organisations are doing the first and calling it the second.
Information is raw. It is a list of indicators. It is a feed of IP addresses. It is a report that says “APT29 is targeting the energy sector.” That is information. It is data. It has not been assessed. It has not been tested against your specific context. It has not been evaluated for reliability. It has not been analysed.
Intelligence is assessed judgement that answers a specific question with a stated confidence level, tested against bias and honest about what you do not know as much as what you do. It reaches the right person, in the right format, at the right time, so they can make a decision.
A CISO does not need more information. A CISO needs intelligence that says:
“Based on our analysis, the most likely threat to our organisation in the next quarter is credential theft via supply chain compromise in our Tier 2 SEA manufacturing partners, and our current controls are insufficient because we have not implemented hardware MFA on our CI/CD pipeline and we have post-incident reviews showing phishing attacks against domains belonging to our suppliers. The business impact is...”
That is intelligence. That changes behaviour. That influences a decision.
The SANS 2025 CTI Survey found that 93% of organisations now have some form of CTI capability. That sounds impressive until you realise that only 55% measure whether their CTI programme is actually effective. The rest are flying blind, spending money on feeds or producing reports nobody reads and wondering why the board does not take them seriously.
It burns out the team too. Analysts who feel their work goes unread stop caring, then they leave.
I will also say it loud - Good CTI is hard. There is a hierarchy to how much pain your intelligence can inflict on an adversary, and David Bianco captured it perfectly in 2013 with the Pyramid of Pain. At the bottom are hash values and IP addresses. These are trivial for an adversary to change, and detecting them gives you only momentary advantage. Move up and you hit domain names and network artefacts, harder for the adversary to walk away from.
At the top sit tools and, ultimately, TTPs: the tactics, techniques, and procedures that define how an adversary actually operates. When your intelligence capability can detect and deploy countermeasures at the TTP level, the adversary has to fundamentally retool. That is painful for them. That is where intelligence stops being reactive and starts imposing cost.
Most CTI teams live at the bottom of the pyramid. The good ones climb it deliberately.
Frameworks like Lockheed Martin’s Cyber Kill Chain, MITRE ATT&CK and the Diamond Model of Intrusion Analysis give your team structured ways to map adversary behaviour, attribute campaigns and prioritise where to invest defensively. I will break each of these down in detail in future articles. But the point here is simple: none of them deliver value if your team is still stuck at the bottom of the Pyramid of Pain, collecting data and calling it intelligence.
What Is the Intelligence Lifecycle
The intelligence lifecycle has been refined by every serious intelligence organisation in the world. It works. Every time. In every domain. It does not matter whether you are tracking state-sponsored actors, assessing fraud risk or countering terrorism. The cycle is the same.
Planning and Direction. This is where you define what you actually need to know. In intelligence terms, these are your Priority Intelligence Requirements, or PIRs. I will come back to this because it is the single biggest failure point in most CTI programmes.
Collection. You go and find the information that answers your PIRs. Not everything. Not every feed. Not every vendor alert. The specific information that helps you answer the specific questions your leadership needs answered. It could be a human source, a peer firm, or a dark web forum.
Processing. You take raw data and make it usable. You deduplicate. You normalise. You translate. You check sources. This is unglamorous work and it is critical. Without it, your analysts are working with garbage.
Analysis. This is where the real thinking happens. You take processed information and you produce assessed judgement. You consider alternative explanations. You test your assumptions. You flag what you are confident about and what remains uncertain. You do not hide behind jargon or ambiguity. You commit to an assessment and you explain your reasoning.
Dissemination. You deliver the finished product to the person who needed it, in the format they can use, at the time they need it. Not a 40-page report. Not a dashboard nobody checks. A clear, concise brief that tells someone what to do.
Feedback. The consumer tells you whether the intelligence was useful, whether it answered their question, whether they need something different. This closes the loop. Without feedback, you are guessing what matters.
Most CTI teams execute maybe two of these steps. They collect data and skip straight to telling you about it. The middle steps, where the actual intelligence work happens, get compressed or ignored entirely. Then they wonder why the CISO does not read their reports. It is like skipping the cooking and serving raw ingredients on a plate. Technically you have provided food. Nobody is going to eat it.
Stakeholder feedback is the single biggest gap I see today.
The OODA Loop: Speed Kills
Colonel John Boyd of the United States Air Force figured something out in the 1960s that most CISOs still have not internalised. Boyd was a fighter pilot. He studied why some pilots consistently won dogfights and others did not. The answer was not better aircraft. It was faster decision making, or as I call it here at DTNA, decision velocity.
Boyd called it the OODA loop. Observe, Orient, Decide, Act. The pilot who cycled through that loop faster than their opponent won. Every time. Not because they had more information, but because they made better decisions more quickly. In doing so, they got inside their adversary’s decision cycle. The other pilot was still reacting to the last move while Boyd’s pilot was already three moves ahead.
This applies directly to cyber defence.
I saw it firsthand when working on security for mobile banking applications when they first launched. The moment those apps went live, the entire world started reverse engineering them. Not just the criminals. Legitimate technical users building their own API integrations, open banking enthusiasts, researchers. Everyone.
We had to stay ahead of auth fuzzing attacks, gateway permission bypasses and binary reverse engineering happening in real time. The OODA loop was not days or weeks. It was hours. If you were not observing what people were doing with your application, orienting to the new attack patterns, deciding on updated rules, and acting before the next wave, you were already compromised.
Today, AI is accelerating this further. Automated API discovery, AI-assisted reverse engineering, machine-speed reconnaissance. The speed of the loop keeps increasing and most organisations are still cycling at a pace that belongs in the last decade.
Your adversaries have an OODA loop. They observe your environment, they orient themselves to your defences, they decide on an approach, they act. Your defenders have an OODA loop too. The question is simple: who cycles faster?
And most people forget this part. The threats are not only from criminals. Your own technical ecosystem, developers building integrations, third parties connecting to your APIs, users finding creative ways to use your services in ways you never intended, all of that is part of the threat landscape. Intelligence needs to cover the full picture, not just the adversary with a skull and crossbones avatar on a dark web forum.
If your intelligence team takes two weeks to process a report about a new technique, and the adversary deployed that technique three weeks ago, you are already behind. Your OODA loop is slower than theirs. They have moved on. They have adapted. You are defending against the last war.
The intelligence lifecycle is not just a theoretical framework. It is an operational tempo. Every step that gets compressed, every shortcut that gets taken, every report that sits unread in someone’s inbox: that is your OODA loop slowing down. And when your OODA loop is slower than your adversary’s, you lose.
The fusion intelligence model I describe later in this article exists precisely to accelerate the OODA loop. Peer institutions sharing indicators in real time. Countermeasures deployed the same day. Attack patterns blocked before they reach your infrastructure. That is what a fast OODA loop looks like in practice. Not faster dashboards. Faster decisions that lead to faster action.
Boyd was talking about fighter jets, but the principle is universal. In cybersecurity, the organisation that observes threats faster, orients to them more accurately, decides on a response with greater confidence, and acts before the adversary can adapt: that organisation wins. Decision velocity. The rest are just buying expensive technology and hoping for the best.
Priority Intelligence Requirements: The Art of Asking the Right Question
If you get nothing else from this article, get this: the quality of your intelligence is determined by the quality of your requirements. This is not optional. This is the foundation.
A Priority Intelligence Requirement is a specific question that, when answered, directly supports a decision your organisation needs to make. It is not “tell me about threat actors.” It is not “what is happening in the threat landscape.” Those are not requirements. Those are existential crises dressed up as questions.
A good PIR looks like this:
“What credential harvesting techniques are being used against financial services organisations in Southeast Asia in the current quarter, and which of our authentication controls are most likely to be bypassed?”
Or this:
“Which third-party vendors in our supply chain have been compromised or targeted in the past 90 days, and what is the assessed likelihood of lateral movement into our environment?”
Or this:
“What is the assessed capability and intent of threat groups targeting our sector to exploit vulnerabilities in our externally facing applications, specifically our customer portal and API gateway?”
Each of these asks one question. Each is focused on a specific fact, event, or activity. Each provides intelligence required to support a single decision. Each can be answered with evidence and analysis, not speculation.
A bad PIR looks like this: “Tell me about APTs.” Or: “What are the current cyber threats?” Or: “Give me an update on the threat landscape.”
These are not requirements. They are invitations to produce noise. You might as well ask your analyst to “tell me about the weather in Wales” and then be disappointed when they do not predict tomorrow’s three days of summer.
The analogy I keep coming back to is this. If you have ever used an AI tool, a chatbot, anything that responds to prompts, you know that the quality of the output depends entirely on the quality of the input. A vague prompt gets you a vague answer. A specific, well-structured prompt gets you something useful. Prompt engineering is, at its core, the same discipline as writing intelligence requirements. Garbage in, garbage out. Quality requirements produce quality intelligence. Vague requirements produce expensive data collection.
Your PIRs should be written by your stakeholders (both on your LT and your peers) with input from your intelligence analysts. They should be reviewed quarterly. They should change as your organisation’s risk profile changes. And they should be the single document that drives everything your CTI team does.
Source Confidence: Not All Information Is Created Equal
One of the biggest failures in commercial CTI is treating all sources as equally reliable. They are not.
Military and government intelligence services solved this problem decades ago with the NATO Admiralty System, also known as the source reliability rating. It is a simple framework. Two independent scales. One rates the source. The other rates the information.
Source reliability runs from A to F:
A is completely reliable. No doubt. Proven track record. B is usually reliable. Minor doubt, but historically accurate. C is fairly reliable. Some doubt, but has been right before. D is not usually reliable. Significant doubt, but occasionally useful. E is unreliable. History of invalid information. F means reliability cannot be judged. New source, no track record.
Information credibility runs from 1 to 6:
1 is confirmed by other independent sources. 2 is probably true, logical and consistent but not independently confirmed. 3 is possibly true. 4 is doubtful. 5 is improbable. 6 means truth cannot be judged. We also call this RUMINT.
When an intelligence analyst tags a piece of information as B2, they are saying: “The source is usually reliable, and this information is probably true but not yet confirmed.” When something is tagged D5, they are saying: “This source has a dodgy track record and the information itself does not hold up.”
This is not bureaucracy. This is intellectual honesty. And it is the difference between a CISO acting on assessed intelligence and a CISO acting on RUMINT.
Let me put it simply. Someone you have never met tells you that Dan Tinsley has dyed his ginger beard bright pink and it is down to his chest. You have never spoken to this person before. They have no evidence. And everyone who knows them says they are always telling stories. That is an F5 on the Admiralty Scale. Unreliable source, improbable information. You would not make a business decision based on that. But this is exactly what happens when a CTI team takes an unverified post from an anonymous forum and treats it the same as a first-hand incident response report from a trusted peer.
Most commercial CTI teams do not rate their sources at all. They consume vendor feeds, open source reports, government advisories and peer sharing groups and treat them all as equivalent. They are not. A first-hand technical analysis from an incident response engagement is worth more than a blog post summarising someone else’s blog post. A piece of intelligence shared through a trusted ISAC with restrictions is worth more than a tweet from a security researcher with 2,000 followers and no disclosed methodology.
Start rating your sources. Use the Admiralty System. Use something else. But use something. Your analysis is only as good as the information you feed into it.
This pairs naturally with the Traffic Light Protocol. TLP, now at version 2.0, managed by FIRST, gives you five levels for information handling: TLP:RED (named recipients only), TLP:AMBER+STRICT (your organisation only), TLP:AMBER (your organisation and clients on a need-to-know basis), TLP:GREEN (your community but not publicly) and TLP:CLEAR (share freely). Source confidence tells you how much to trust the information. TLP tells you how to handle it. Together, they form the backbone of responsible intelligence sharing.
The Attribution Trap: Be Careful What You Call Things
This really matters, and almost nobody in commercial CTI talks about it properly.
When a threat intelligence report says “a state-sponsored threat actor,” what does that actually mean? Does it mean a government military unit conducting offensive cyber operations? Does it mean a criminal group that the government tolerates because they serve a strategic purpose? Or a private company contracted by a government to conduct operations? Or a group that just happens to be located in a particular country with no formal government relationship at all?
These are very different things. They have very different implications for your risk profile. They require very different defensive strategies.
The tendency in CTI teams is to use geographic shorthand. “State-sponsored actor from Country X is targeting the financial sector.” This creates an immediate cognitive bias. Your brain assigns intent, capability and motivation based on the country label. If the label says one country, you think espionage and intellectual property theft. If it says another, you think destructive attacks and pre-positioning. These shortcuts are dangerous because they are often wrong, and even when they are partially right, they obscure the nuance that actually matters for your defensive planning.
Worse, in a global MNC they can unintentionally cause racial profiling. When your board member is from said Country X, and you just handed them a report that says their entire country is hacking the company, you get egg on face quickly.
Professional intelligence agencies break this down differently. They assess capability separately from intent. They distinguish between government military apparatus, intelligence service operations, contracted private offensive teams, tolerated criminal enterprise and independent criminal groups. The distinction matters because each of these requires a different risk assessment and a different defensive posture.
Writing intelligence is an art form. I have read thousands of intelligence reports over my career. The good ones remove bias systematically. They use structured analytical techniques to challenge assumptions. They present alternative hypotheses. They tell you what they do not know as clearly as what they do know. The bad ones confirm whatever the analyst already believed before they started writing.
Removing bias from intelligence writing is hard. It requires discipline, peer review and a willingness to be wrong. One of the best books ever written on this is “Psychology of Intelligence Analysis” by Richards Heuer, published by the CIA’s Centre for the Study of Intelligence. It is free to download. It should be mandatory reading for every CTI analyst. It will change how you think about your own thinking.
What Should Actually Land in the CISO’s Inbox
Let me paint the picture of what good intelligence looks like when it reaches a decision maker.
Strategic intelligence is for the board and the leadership team. It tells you the big picture. It says: “Over the next twelve months, we assess with moderate confidence that state-directed operations targeting our sector will increase, driven by geopolitical tensions around trade policy. Our exposure is concentrated in three areas. Here is what we recommend.” This lands monthly or quarterly. It shapes budgets, architecture and programme direction.
Operational intelligence is for the security leadership team. It tells you how adversaries are operating. It says: “The threat group we have been tracking has shifted from phishing to supply chain compromise. They are targeting cloud CI/CD pipelines using stolen developer credentials obtained via fake LinkedIn profiles offering dev jobs linked to units in the DPRK Reconnaissance General Bureau. Here is the pattern. Here is what we should check.” This lands weekly or as the situation changes. It shapes hunting priorities and defensive adjustments.
Tactical intelligence is for your SOC and incident response teams. It is machine-readable where possible. It says: “Block these IPs. Hunt for these file hashes. Look for this registry key.” This is the most automated layer and should require the least human effort. If your analysts are spending most of their time producing tactical intelligence with copy and paste worn out, something is wrong. Machines should do this.
A CISO who receives all three, properly structured, properly timed and properly prioritised, is a CISO who can actually make decisions. Compare that to the inbox full of dashboards and vendor alerts. Night and day.
AI Is Going to Change This (If We Let It)
Let me be direct about AI in threat intelligence. It is not going to replace analysts. But it is going to transform the parts of the cycle that do not require human judgement.
Processing is where AI will have the most immediate impact. The tedious work of deduplicating indicators, normalising data formats, correlating across feeds, translating foreign language reports and extracting indicators from unstructured text. AI is already doing this. Over a third of organisations now use AI in their CTI workflows, and that number is climbing fast.
Collection will benefit from AI-driven monitoring. Natural language processing can scan tens of thousands of sources: dark web forums, paste sites, code repositories and social media, extracting relevant information faster than any human team. The key word is “relevant.” AI needs good requirements to collect against. Which brings us back to PIRs. See a pattern here?
Analysis is where it gets interesting and where the risk lives. AI can help structure analysis, surface patterns humans would miss and generate first drafts of assessments. But analysis requires judgement. It requires understanding context. It requires knowing when to say “I do not know.” AI is not good at admitting uncertainty. I use AI tools daily in my own work and the difference between giving the tool a specific, well structured requirement versus a vague instruction is night and day. Same discipline, different system. The best model is AI augmenting human analysts, not replacing them. Let the machine handle the volume. Let the human handle the thinking.
Dissemination is ripe for transformation. AI can tailor intelligence products to different audiences automatically. The same underlying analysis, packaged as an executive brief for the board, a technical brief for the SOC and a risk assessment for the compliance team. Different formats, same assessed judgement. This saves analyst time and improves consistency.
The prompt engineering analogy applies here too. If you feed an AI tool a well-structured PIR, it can help you collect, process and draft analysis at speed. If you feed it “tell me about cyber threats,” you get noise at scale. The discipline of intelligence requirements becomes even more important when AI is amplifying your process.
Fusion Intelligence: Breaking Down the Silos
One of the areas I am most focused on is fusion intelligence. The idea is simple: bring together different teams, different disciplines and different data sources to produce intelligence that none of them could produce alone. In practice, it changes everything about how an organisation understands and responds to threats.
Let me give you a real example. When I worked in financial services, I built what I called a security intelligence function. Threat intel came in from peer institutions sharing real-time data through trusted channels. We would take that intelligence and convert it directly into engineering countermeasures. Literally writing DDoS rules or scripts to block attack patterns that had been detected hitting other banks in our sector. Not two weeks later after a vendor report. The same day. Sometimes the same hour. Engineering became the PIR requestors.
I remember the NTP amplification and EDR bypass attacks vividly. Peer institutions would share indicators in real time. We would take those indicators, validate them against our own telemetry and push patches into our infrastructure before the attack ever reached us. That is fusion intelligence in practice. That is what happens when you stop writing reports and start building countermeasures. Bringing together engineers, pen testers and OT/ICS devs is powerful.
But it goes further than blocking known attacks. The real value is in looking at how other organisations have been breached and asking: could that happen to us? You take the intelligence, you replay those scenarios against your own environment and you assess whether you have the capability to detect and stop it. If the answer is no, that becomes an architectural decision. Not a quick fix. Not a patch. A deliberate investment in building the capability that your intelligence tells you is missing.
These are the questions every CISO should be asking. A peer organisation in our sector was breached through their fish tank platform (yes, this was real). Do we have the controls to prevent that? If not, why not? Is it a tooling gap? A budget gap? A skills gap? This is intelligence driving capability planning. This is how the intelligence lifecycle produces outcomes that actually matter, not another PDF that sits in a SharePoint folder.
Let me be blunt. If you have an Exchange server sitting on your external perimeter, unpatched, vulnerable to something like Hafnium, and your intelligence team is sending you beautifully formatted reports about sophisticated state-directed operations using zero-day exploits, you have a prioritisation problem. The sophisticated stuff is real. But the unpatched Exchange server is going to kill you first.
Internal intelligence, your own vulnerability data, your own asset inventory, your own telemetry, tells you that. External intelligence tells you who might exploit it and how. You need both. But you need to fix the basics before you worry about the advanced threats.
Now here is the part that most organisations miss entirely. Cyber does not exist in isolation. A cyber attack is not just a technical event. It is a business event. It results in loss of revenue, loss of trust, regulatory action and in some cases loss of life. When you frame it that way, the silos between security teams start to look absurd.
From my experience in advisory roles, I have seen serious organised criminal groups leverage cyber means to advance their operations in ways that would surprise most CISOs. AI-generated deepfakes used to authorise fraudulent wire transfers. Rogue mobile banking applications deployed at scale. Social engineering campaigns so sophisticated they bypass every KYC control you have. Ransomware deployed to lock factories or encrypt intellectual property because they know your cyber insurance policy, and that you will pay. These are not isolated cyber threats. They are multidisciplinary criminal operations that cross the boundary between cyber and fraud.
If you overlay fraud and ops telemetry with your cyber intelligence, patterns emerge that neither team would see alone. The same infrastructure used in a phishing campaign might also be linked to account takeover fraud. The same compromised credentials showing up in your darknet monitoring might already be in use for fraudulent transactions. Cyber, fraud and engineering teams need to talk to each other because ultimately they are all protecting the same thing: business outcomes.
Let us stop calling it a “cyber attack” as if it only lives in the technology domain. Call it what it actually is: an event that impacts business resilience and costs you money. Whether that is intellectual property walking out the door, health data being exfiltrated, critical infrastructure losing service or in the most serious cases medical devices like heart monitors being disrupted. The consequences are real and they cross every organisational boundary we have built.
The output of the intelligence lifecycle is called “product.” That is a formal term, not to be confused with a software product you buy off the shelf. Intelligence product is the assessed, finished intelligence that answers a requirement and supports a decision. In a fusion model, that product is richer because it draws on more sources, more perspectives and more context than any single team could provide. And critically, it drives action. Not just awareness. Action.
Get the Basics Right Before You Buy the Fancy Stuff
Something I say to every CISO I work with, and it is not always popular. But hey, when has that stopped me.
If 90% of your basics are not right, having someone paid to tell you your house is on fire is not going to help you. If your patching cadence is a disaster, if your privileged identity and access management is a mess, if you do not have MFA everywhere it should be, if your telemetry is incomplete, if you cannot see what is happening on your own network, then the most sophisticated threat intelligence programme in the world will not save you.
Think about it this way. The Death Star was the largest man-made structure in the galaxy. It could destroy planets. And it was taken out by a bottle rocket to the tailpipe. That is what happens when your intelligence function fails to identify the one weakness that actually matters. The Imperial Intelligence Corps had all the resources in the universe and they still did not figure out what the Rebels knew until it was too late. Your organisation probably has its own thermal exhaust port sitting somewhere on its external perimeter. Internal intelligence is how you find it before someone else does.
(I used this image at a talk over at NUS on Threat Led Architecture)
I have lost count of the number of times someone has come to me wanting to deploy a fancy SD-WAN solution when they have not correctly identified which assets belong in which segmentation zones. It is like buying a 911 GTRS before you have learned to drive. Impressive. Expensive. Going to end badly.
I learned this lesson myself, early in my career, the hard way. I was trying to resolve a denial-of-service vulnerability on a global PWAN system. Made a configuration change that I was confident would fix the problem. Instead, it locked out access entirely. Nothing like bringing down the thing you were trying to protect to teach you humility about the basics. That one is a story for a beer, not a Substack article. But the lesson stuck: understand what you are changing, understand the dependencies and never assume you are too smart to make the simple mistake. Intelligence is not just about knowing the threat. It is about knowing your own environment well enough to act on that intelligence without creating a new incident.
Your first and most valuable source of intelligence is your own internal network. Your logs. Your incident data. Your vulnerability scans. Your asset inventory. This is the intelligence that tells you where you are actually exposed. Before you subscribe to a single external feed, you need to understand what your own environment is telling you.
After that, your peer relationships. Your ISAC membership. Your informal networks of security leaders who will tell you what they are seeing because they trust you. This strategic intelligence, shared between practitioners who face similar threats, is worth more than any vendor subscription.
Tactical intelligence should be automated. Indicators of compromise, detection signatures, blocking rules. These should flow into your security stack with minimal human intervention. This frees your analysts to focus on the big-ticket items: capability gaps, architectural weaknesses, strategic risk.
Intelligence to Threat Informed Architecture
When I worked in a previous role, I developed what I called Threat Informed Architecture. The concept was straightforward, but it changed how the entire security programme operated.
Intelligence identifies a specific gap in your defensive capability. Maybe a peer institution was breached through a technique you had no detection for. Maybe a new TTP emerged that your architecture could not stop. That gap gets formally logged as a countermeasure requirement. It feeds directly into capability and budget planning. It gets addressed through deliberate architectural change, not just a quick-fix patch or a hastily written SIEM rule.
The range is broader than people expect. We put countermeasures in place for everything from potential cryptographic key compromise, where intelligence suggested signing ceremonies needed review, through to the evolution of phishing campaigns. Phishing has moved from basic domain masking all the way through to AI-generated deepfakes and your countermeasures need to evolve with it.
EDR, DKIM, email authentication controls that intelligence tells you are being bypassed in new ways. Command and control behaviour analysis, where intelligence about adversary infrastructure helps you detect C2 callbacks your existing signatures miss.
The countermeasure becomes a project. It has a business case. It has a timeline. It has a budget line. And critically, it traces back to a specific piece of intelligence that explains why you are spending the money.
Yes, I am suggesting your intelligence team should create work that involves spreadsheets. I know. But the spreadsheet is how you get the budget and the budget is how you get the capability.
When the board asks “why are we investing in this capability?” the answer is not “because a vendor said so.” The answer is “because intelligence assessed that this specific threat is likely to affect organisations like ours and we currently lack the capability to detect or prevent it.” That is a conversation a board can engage with.
Intelligence should feed directly into your security programme through architectural planning. Fix the things intelligence is telling you are at risk. Not everything. Not every theoretical threat in the universe. The specific, assessed, prioritised threats that your intelligence function has identified as relevant to your organisation. That is the link between intelligence and action. That is what makes the whole lifecycle worth the effort.
This is where a framework like FAIR (Factor Analysis of Information Risk) helps. FAIR, developed by Jack Jones, gives you a way to quantify risk in terms that boards understand: probable frequency and probable magnitude of loss. It is hard to implement properly. I have seen organisations spend six months building a FAIR model when a conversation with their own pen test team would have told them where the problems were in an afternoon. But if you already know you have web applications with known vulnerabilities, or shadow IT that nobody owns, or third-party integrations that have never been assessed, you do not need a complex risk model to know where to start. Intelligence confirms it and adds the adversary context that turns a vulnerability list into a priority list.
The Art of Learning From Other People’s Disasters
Intelligence does not only serve defensive operations. It drives proactive threat hunting and resilience testing. And when done right, this is where your investment starts paying for itself.
Threat hunting is the practice of actively searching your environment for threats that your automated defences have not detected. The difference between good threat hunting and aimless log searching is intelligence. A hunt hypothesis driven by a solid PIR, informed by current adversary TTPs, targeted at specific gaps in your detection capability: that is productive. A hunt that starts with “let us look for anything suspicious” is a waste of everyone’s time. I have sat in rooms where that was literally the brief. It never ends well.
This is where the intelligence lifecycle connects directly to your hunting programme. Your analysts produce an assessment: a specific threat group is using a particular technique to compromise organisations in your sector. Your hunters take that assessment and go looking for evidence that the technique has been used against you. If they find it, you have an incident. If they do not, you have validated a control or identified a detection gap. Either way, you have produced actionable intelligence about your own environment. That feeds back into the cycle. That is the OODA loop in practice.
Resilience testing takes this further. You take the intelligence about how peer organisations were breached, and you attempt to replay those scenarios in your own environment. Not in theory. In practice. Red team exercises, purple team engagements, tabletop exercises, all driven by real threat intelligence rather than hypothetical scenarios from a consultant’s slide deck. The question is always the same: if this happened to them, would we survive it?
It does not need to be in your own industry. Some of the best lessons I have learned about operational resilience came from sectors that have nothing to do with cybersecurity. That is not a weakness. That is a cheat code.
I look at pharmaceutical and healthcare incidents constantly. When the Irish Health Service was hit by ransomware in 2021, it took down everything. Patient records, diagnostic systems, appointment scheduling. The entire national health infrastructure went offline in hours. The post-incident analysis revealed failures in redundancy, communication and decision making under pressure that apply to any critical infrastructure, not just healthcare.
I have looked at automotive manufacturers losing entire production lines. Honda and Jaguar Land Rover in the UK both suffered significant operational downtime from cyber incidents. When a manufacturing plant stops, the financial impact is measured in millions per hour. That is intelligence I take and apply retrospectively: what would happen if this hit our environment? Do we have the segmentation? Do we have the failover? Do we have the detection? Different sector, same failure patterns.
Aviation is the one I keep coming back to. If you have ever seen me speak, you know I talk about aviation a lot. I have always been fascinated by how air traffic controllers and pilots operate under extreme pressure. The standard operating procedures. The checklists. The crew resource management. The way a cockpit is designed so that when everything goes wrong, the pilots have a structured process for dealing with it. They do not panic. They do not freelance. They follow the procedure, they communicate clearly and they make decisions based on the information available.
When things go properly wrong in cybersecurity, when the incident is real and the pressure is on and the board is calling, the organisations that survive are the ones that have practised. And the best practice scenarios are not invented by consultants. They are drawn from real intelligence about real incidents in real organisations. Cross-industry learning is massively undervalued in our field. A breach in a bank, a ransomware attack on a hospital and a supply chain compromise in manufacturing: these are different events with remarkably similar root causes. If your intelligence function is not looking across sectors for lessons, you are missing half the picture.
There is a much deeper conversation to be had about how intelligence feeds directly into security architecture. How the decisions you make about segmentation, redundancy, detection coverage and resilience engineering should all be driven by intelligence about what you are actually defending against. Intelligence and architecture are not separate disciplines. They are two sides of the same coin.
Decision Velocity: The Real Objective
Everything I have written so far builds to this point. This is where DTN Advisory is heading and this is what I believe the future of intelligence-led security looks like.
Decision velocity. The speed at which an organisation can take reliable, confident intelligence and turn it into action.
Not just any action. The right action. Prioritised, risk-informed and executed with the kind of precision that comes from knowing exactly what you are dealing with and why it matters.
The utopia looks like this. Credible intelligence, rated A1 on the Admiralty Scale, mapped against your infrastructure and business risk domains. Tangible threat analysis based on likelihood and impact, not fear and guesswork. Automated remediation that executes without waiting for three change advisory boards and a steering committee. The intelligence comes in. The decision is made. The action is taken. The loop closes.
This comes from my network engineering days. If you have ever worked with Spanning Tree Protocol, you know what I mean. STP exists to detect switching loops and manage failover across redundant Ethernet paths. It automatically detects a problem, recalculates the topology, and converges on a new path. It does not wait for a human to decide which switch should be the root bridge. It does not send a report to management. It acts, based on predefined logic, at machine speed.
Why can we not do this at scale for security decisions?
I am not suggesting we remove humans from the loop entirely. Analysis requires judgement. Strategic decisions require context. But there is a vast middle ground between “fully manual decision making that takes weeks” and “fully automated response that nobody trusts.” That middle ground is where intelligence-driven automation lives. Where the intelligence function produces assessed, confident judgements that feed directly into automated defensive actions. Where the OODA loop operates at the speed the threat environment demands, not at the speed your change management process allows.
This is fundamentally about scalable resilience engineering. Ross Anderson wrote brilliantly about this in “Security Engineering,” now in its third edition and freely available online. Anderson’s insight is that security is not a product you buy. It is an engineering discipline. And engineering disciplines scale. They have principles. They have known failure modes. They have mathematical models for reliability.
Intelligence-led decision velocity is the application of that thinking to threat response. You take the proven frameworks, the lifecycle, the OODA loop, the source evaluation, the structured analysis and you engineer them into systems that can operate at scale. Not replacing the human analyst. Amplifying them. Giving them the tools to make faster, better decisions and the infrastructure to execute those decisions before the adversary has completed their next OODA cycle.
I think about this through the lens of capability planning. If you have ever studied what Singapore’s Urban Redevelopment Authority does with town planning, you will understand the analogy. The URA does not plan for next month. They plan decades ahead, with clear end states, phased development and deliberate infrastructure investment. Security leaders need to think the same way. Not fifty years out, but at least one or two. What is your end state? What capability are you trying to build? Technology changes. AI is changing everything. But the principle of having a deliberate plan, informed by intelligence, with a clear destination: that does not change.
This is what I mean when I say DTN Advisory is intelligence-led. It is not a slogan. It is an operating model. Everything we do, every piece of advice we give, every capability we help organisations build, starts with the same question: what is the intelligence telling us, and how fast can we act on it?
Wrapping up
Intelligence is not data collection. It is not dashboards. It is not vendor subscriptions. It is the disciplined application of a proven lifecycle to produce assessed judgement that helps decision makers act.
The frameworks exist. The tradecraft is documented. The books are written. The only thing missing in most organisations is the willingness to do the hard work of actually following the process.
Get your PIRs right. Rate your sources. Remove your biases. Write intelligence that answers questions, not intelligence that describes problems. Deliver it to the right person in the right format. Close the feedback loop. Automate the tactical layer. Focus your analysts on the strategic and operational questions that machines cannot answer.
And for the love of all things analytical, go read that book :)
One More Thing
DTN Advisory Labs (The fancy part) is building something in the AI space to address some of the challenges I have described here. I am not ready to talk about it yet. I realise that is deeply annoying. A Welshman teasing you with a cliffhanger about AI and intelligence automation. But if any of what I have written resonates with the problems you are facing, keep watching this space.
If you want to talk about how to build this capability in your organisation, connect with the DTNA team.
Dan Tinsley is the founder of DTN Advisory, providing cybersecurity, resilience, and intelligence advisory services from Singapore across the Asia Pacific region.
Dan’s Reading List
If you want to build a serious CTI capability, these books are not optional. They are foundational.
“Structured Analytic Techniques for Intelligence Analysis” by Richards J. Heuer Jr. and Randolph H. Pherson. Now in its third edition. This is the bible. Sixty-six structured techniques for removing bias, testing assumptions, and producing better analysis. Adopted by dozens of intelligence agencies globally. It sits on my desk. It should sit on yours.
“Psychology of Intelligence Analysis” by Richards J. Heuer Jr. Published by the CIA’s Centre for the Study of Intelligence. Available free online. This book will fundamentally change how you think about your own cognitive biases. If your analysts have not read this, they are guessing and they do not know it.
“Critical Thinking for Strategic Intelligence” by Katherine Hibbs Pherson and Randolph H. Pherson. Now in its fourth edition. Practical application of critical thinking skills specifically for intelligence work. The latest edition includes sections on AI implications and deepfakes, which is timely.
“Intelligence Analysis: A Target Centric Approach” by Robert M. Clark. Now in its seventh edition. An alternative methodology to the traditional intelligence cycle that treats targets as complex systems. Clark has over fifty years in the intelligence community, including time as a senior CIA analyst.
“Measuring and Managing Information Risk: A FAIR Approach” by Jack Freund and Jack Jones. The definitive guide to quantifying information risk. Essential reading if you want to connect intelligence output to business risk language that boards understand.
“Security Engineering: A Guide to Building Dependable Distributed Systems” by Ross Anderson. Now in its third edition and freely available online. Anderson is a professor at Cambridge and this book is a masterclass in how to think about security as an engineering discipline. If decision velocity and scalable resilience mean anything to you, start here.
These are not light reading. They are not blog posts. They require actual effort. But a team that has internalised these will out-analyse a team with ten times the budget and none of the tradecraft. Every single time.
Article Sources and References
SANS 2025 CTI Survey — Annual survey on the state of cyber threat intelligence across global organisations. Covers programme maturity, staffing, tooling, and effectiveness measurement. sans.org/white-papers/cti-survey
David Bianco, “The Pyramid of Pain” (2013) — A model for understanding the relationship between indicator types and the cost imposed on adversaries when those indicators are detected. Originally published on Bianco’s blog and widely adopted across the CTI community. detect-respond.blogspot.com
NATO Admiralty System — Also known as the NATO System for Evaluating Sources and Information. A two-axis framework (source reliability A-F, information credibility 1-6) used by military and intelligence services globally for source evaluation.
Traffic Light Protocol v2.0, FIRST — The standard for information sharing classification maintained by the Forum of Incident Response and Security Teams. Updated to v2.0 with five levels: RED, AMBER+STRICT, AMBER, GREEN, and CLEAR. first.org/tlp
Colonel John Boyd, OODA Loop — Observe, Orient, Decide, Act. A decision cycle framework developed by USAF Colonel John Boyd based on his study of air combat manoeuvring. Widely applied to military strategy, business, and cybersecurity.
Richards J. Heuer Jr., “Psychology of Intelligence Analysis” — Published by the CIA’s Centre for the Study of Intelligence. A foundational text on cognitive biases in intelligence analysis. Available free online. cia.gov/resources/csi/books-monographs/psychology-of-intelligence-analysis
Richards J. Heuer Jr. and Randolph H. Pherson, “Structured Analytic Techniques for Intelligence Analysis,” 3rd Edition — Sixty-six techniques for structured analysis, bias mitigation, and analytical rigour. Adopted by intelligence agencies globally.
Katherine Hibbs Pherson and Randolph H. Pherson, “Critical Thinking for Strategic Intelligence,” 4th Edition — Practical critical thinking for intelligence professionals. Latest edition covers AI implications, deepfakes, and emerging analytical challenges.
Robert M. Clark, “Intelligence Analysis: A Target Centric Approach,” 7th Edition — An alternative to the traditional intelligence cycle that models targets as complex systems. Clark served over fifty years in the US intelligence community including as a senior CIA analyst.
Jack Freund and Jack Jones, “Measuring and Managing Information Risk: A FAIR Approach” — The definitive guide to the Factor Analysis of Information Risk framework. Quantifies risk in terms of probable frequency and probable magnitude of loss. fairinstitute.org
Ross Anderson, “Security Engineering,” 3rd Edition — A comprehensive text on building dependable distributed systems. Covers cryptography, access control, economics of security, and resilience engineering. Freely available online. cl.cam.ac.uk/~rja14/book.html
Lockheed Martin, Cyber Kill Chain — A seven-phase model (Reconnaissance, Weaponisation, Delivery, Exploitation, Installation, Command & Control, Actions on Objectives) for describing the stages of a cyber intrusion. lockheedmartin.com/en-us/capabilities/cyber/cyber-kill-chain.html
MITRE ATT&CK Framework — A globally accessible knowledge base of adversary tactics and techniques based on real-world observations. Covers Enterprise, Mobile, and ICS environments. attack.mitre.org
Diamond Model of Intrusion Analysis — A model relating four core features of any intrusion: adversary, capability, infrastructure, and victim. Developed by Sergio Caltagirone, Andrew Pendergast, and Christopher Betz.
Irish Health Service Executive (HSE) ransomware incident, 2021 — Conti ransomware attack that took down Ireland’s national health IT infrastructure. Post-incident review by PricewaterhouseCoopers published December 2021.
Microsoft Threat Intelligence, Hafnium Exchange Server exploitation — Microsoft’s disclosure and analysis of the Hafnium threat group exploiting zero-day vulnerabilities in on-premises Exchange Server instances, March 2021. microsoft.com/en-us/security/blog/2021/03/02/hafnium-targeting-exchange-servers
The information in this article is provided for general informational purposes only and reflects the author's analysis of publicly available frameworks, policies and data as of the date of publication. It does not constitute legal, regulatory, tax or professional cybersecurity advice. Organisations should seek independent professional advice before acting on any of the information contained here. DTN Advisory accepts no liability for any loss or damage arising from reliance on the content of this article. All references to government frameworks, deadlines and programmes are based on published sources and may be subject to change.
Great points! Seen a lot of the impacts of this first hand, great to peak behind the curtain and see how to get it done properly!