Here is an uncomfortable test, borrowed from a 2026 piece on the fallacies of threat intelligence programs. In the last ninety days, name three operational, detection, or strategic decisions that changed because of something your CTI team produced.
For a lot of teams, that list comes up short. Not because the analysis was wrong, and not because the analysts were lazy. The research was solid, the tracking was careful, the PDF was well formatted. It just never changed anything, because nobody finished reading it, and the people who did could not work out what they were supposed to do next.
Writing is the part of threat intelligence that gets treated as an afterthought and is actually the whole deliverable. An unread report is indistinguishable from no report at all. Worse, it consumed analyst hours that could have gone somewhere useful.
This is a practical guide to how to write a threat intelligence report that gets acted on. It covers the BLUF method that intelligence communities have used for decades, the standardized confidence language that separates a professional assessment from a guess, the structure that survives a busy reader, and the specific mistakes that quietly kill otherwise good reports.
Why Reports Get Ignored
Before the method, the diagnosis. Reports fail for four reasons, and only one of them is about writing quality.
They bury the conclusion. The analyst walks the reader through the investigation in the order it happened, building suspense toward a finding on page four. Readers do not read like that. A busy CISO gives your report thirty seconds before deciding whether it earns more.
They describe instead of assess. This is the most common failure in the discipline, and one CTI practitioner named it perfectly: the tendency to admire the problem. The report explains what the malware does in loving detail and never says what it means for this organization or what anyone should do about it.
They forward information without adding judgment. A summary of somebody else's research, passed along with no assessment attached, is not intelligence work. As one widely read CTI study plan puts it, without adding your own assessment you are acting as a human RSS feed, and the effect on your stakeholders is closer to a denial of service attack than a briefing.
They are aimed at the wrong altitude. A board member handed a report full of file hashes cannot act on it. A detection engineer handed a strategic risk narrative cannot either. This is the audience-matching problem covered in the four types of threat intelligence, and it wastes more good analysis than any other single mistake.
Everything below is a fix for one of these four.
The BLUF Method
BLUF stands for Bottom Line Up Front. It means putting your conclusion in the first sentence rather than the last, and it is the single highest-leverage change most analysts can make to their writing.
The convention comes from military correspondence, specifically US Army Regulation 25-50, which requires that Army writing be concise, organized, and to the point. Intelligence communities adopted it for an obvious reason: their consumers are people making consequential decisions under severe time pressure, who will not read to the end of anything. The alternative has an unofficial name too, BLAB, meaning Bottom Line at Bottom, and it is what most people write by default because it mirrors the order in which they did the thinking.
A BLUF is one or two sentences that state the most important finding and why it matters. It is not a topic announcement. Compare these two openings.
Weak, because it announces a subject without saying anything: "This report examines recent activity associated with an initial access broker targeting the manufacturing sector."
Strong, because a decision-maker could act on this sentence alone: "We assess with moderate confidence that credentials for at least three of our regional suppliers are being advertised by an initial access broker, and that a ransomware deployment against one of them is likely within thirty days. We recommend immediate credential rotation for the affected supplier accounts."
The second version tells the reader what is happening, how sure you are, what is likely next, and what to do. If they read nothing else, they can still act correctly.
The Part Most People Miss
BLUF is not just a section at the top of a document. It is a habit applied at every level of the writing.
Each paragraph should open with its own conclusion, the way a topic sentence works, so that a reader can skim the first line of every paragraph and still extract the argument. One analytic insight per paragraph, stated first, supported after. Guidance in intelligence writing courses is explicit about this: build every paragraph around a single finding, lead with it, then provide the context and evidence that back it up.
The practical test is simple. Read only the first sentence of every paragraph in your report, in order. If that sequence tells a coherent story with a clear conclusion, your structure works. If it reads like a list of topics, you have written BLAB with a BLUF stapled to the front.
The So What Test
BLUF gets your finding read. The so-what test is what makes the finding worth reading.
A useful way to think about it is that a report should move through four questions, and most weak reports stop after the first.
What happened is description. It is necessary and it is not sufficient. Why it happened is explanation. So what is implication, meaning what this means specifically for the reader's organization. Now what is recommendation, the action that follows. Some products add what's next, an outlook on how the situation is likely to develop.
The difference in practice looks like this. Describing a phishing campaign's infrastructure is step one. Explaining that the campaign is targeting your sector because of a specific supply chain relationship is step two. Noting that eleven of your employees are in the targeted role and your current email filtering does not catch this lure type is step three. Recommending a specific detection rule and a targeted awareness message to those eleven people is step four.
Only the fourth changes anything. And notice that steps three and four require knowing your own organization, which is exactly why a threat report copied from a vendor blog and forwarded internally is worth so little.
One caveat worth stating honestly. This four-step model applies to analytical products written for known stakeholders with defined requirements. A public vendor report written for a broad audience cannot make organization-specific recommendations, and should not pretend to.
Confidence and Probability Language
Here is where amateur and professional reporting separate most visibly.
Threat intelligence is built on incomplete information. The instinct is to hedge with words like "may," "possibly," "we believe," or "it appears that." The problem is that those words mean different things to different readers. One person reads "may" as a serious warning and another reads it as an analyst covering themselves. The intelligence community solved this decades ago with standardized language, and the FIRST cyber threat intelligence community recommends the same approach for CTI reporting.
There are two separate things to express, and confusing them is the classic beginner error.
Probability is how likely an event or outcome is. Confidence is how much you trust your own judgment, based on the quality and quantity of your evidence.
These are independent. You can be highly confident that something is unlikely. You can have low confidence in an assessment that something is very likely. Collapsing them into one vague statement destroys information the reader needs.
Two different scales for two different questions. Mixing them in one sentence is the most common error in CTI writing.
The probability scale most widely used comes from Intelligence Community Directive 203, which sets out the analytic standards for US intelligence and was last revalidated in 2023. It maps estimative words to numeric ranges so that "likely" means the same thing to everyone: almost no chance (1 to 5 percent), very unlikely (5 to 20), unlikely (20 to 45), roughly even chance (45 to 55), likely (55 to 80), very likely (80 to 95), and almost certain (95 to 99).
Confidence runs on a separate three-level scale. FIRST recommends high confidence when you have good quality information from multiple collection capabilities that supports a clear judgment, moderate when sources are credible but gaps remain, and low when the information is fragmentary or comes from a single unverified source.
The Rule Almost Nobody Knows
ICD 203 contains a specific instruction that is worth committing to memory, because breaking it is extremely common: products that express a confidence level must not combine that confidence level and a degree of likelihood in the same sentence.
So this is wrong: "We have high confidence that the group will very likely target the financial sector." The reader now has two qualifiers stacked on one claim and cannot tell what is being hedged.
This is right: "The group will very likely target the financial sector in the next quarter. We hold this judgment with high confidence, based on corroborated reporting from three independent sources."
Same information, two sentences, no ambiguity. The probability describes the world. The confidence describes your evidence about the world.
Assessment Is Not a Decoration
A useful formula circulating among CTI practitioners is that an assessment equals confidence plus analysis plus evidence plus sources. All four parts. A confidence label attached to an unsupported claim is worse than no label, because it borrows the credibility of rigorous tradecraft without doing the work.
That means saying what your sources were and what their limitations are. ICD 203 lists sourcing as one of its core standards, requiring analysts to describe the quality and credibility of underlying sources including their access, motivation, and potential bias. In CTI terms: a vendor blog, an underground forum post, and your own telemetry are not equally reliable, and your reader deserves to know which one is carrying your conclusion.
The Anatomy of a Report That Works
Structure is not bureaucracy. It is a set of guideposts that let a reader navigate without reading every word, and readers expect them.
A working template. The top three blocks carry most of the value, and most readers never reach the appendix.
A few notes on the blocks that people get wrong.
The title should be findable. "Threat Report, Week 32" is useless in six months. Name the actor, the campaign, or the exposure.
The TLP marking belongs on every page, not just the cover, and it needs to be correct. If you are unsure which label applies, our guide to the Traffic Light Protocol covers the four labels and the handling rules that come with them.
What we know must stay separated from assessment. ICD 203 makes this a formal standard, requiring analysts to clearly distinguish underlying information from assumptions and judgments. In practice this means your reader can always tell which sentences are facts you observed and which are conclusions you drew, and can therefore disagree with your reasoning without disputing your evidence.
The assessment section is also where alternative explanations belong. Considering a plausible alternative and explaining why you discounted it is not weakness. It is the thing that separates analysis from advocacy, and ICD 203 lists it as a standard for exactly that reason.
Recommended actions need owners and deadlines or they are wishes. "Consider reviewing VPN logging" changes nothing. "The infrastructure team should enable and forward VPN authentication logs to the SIEM before Friday" is a task someone can complete.
The appendix is where the technical bulk goes: indicators, techniques mapped to MITRE ATT&CK, and detection logic. Putting it at the back is deliberate. It serves a different reader than the top of the document does.
Write for the Altitude, Not for Yourself
The same investigation can produce three legitimate products, and the mistake is producing one and sending it to everybody.
An executive product is short, is written in business risk terms, contains no hashes, and answers what this costs us and what we should fund. A SOC or detection product leads with the behaviours and the detection logic and can assume technical fluency. A threat hunting or IR product carries the full actor context, the campaign timeline, and the reasoning.
One caution that is easy to get backwards. When people say "stakeholders," most analysts immediately picture leadership. But a strong argument runs the other way: the tier one SOC analyst deciding whether an alert is a false positive, and the employee deciding whether to click a link, are making the decisions that actually determine whether an intrusion happens. Writing that only ever aims upward is a form of glory-seeking that leaves the most consequential readers unserved. Notably, practitioners repeatedly report that tactical CTI is the most useful output for SOCs and the most frequently neglected.
Mistakes That Quietly Kill Good Reports
A short list of the recurring ones.
Writing the report in the order you did the investigation, rather than the order the reader needs. Using vague hedges instead of standardized probability language. Attaching a confidence level to a claim with no sourcing behind it. Mixing confidence and likelihood in one sentence. Recommending actions with no owner. Sending the same document to four audiences. Producing a weekly report on a schedule long after anyone stopped reading it, because it has become a ritual. And forwarding vendor research with no assessment of what it means for your own environment.
That last one is worth dwelling on, because it is the most common of all and the easiest to fix. Adding one sentence to a forwarded report changes its nature entirely: "Based on this reporting, we assess with moderate confidence that our current EDR and network controls would detect this actor's described techniques, with the exception of the DNS tunnelling method described in section four, which we are investigating." That single sentence is the difference between forwarding and analysing.
Test It Before You Send It
Three quick checks, in order.
The first-sentence test. Read only the opening sentence of each paragraph. Does it hold together as an argument?
The stranger test. If someone read only your BLUF and nothing else, would they take the correct action? If not, the BLUF is a topic sentence, not a conclusion.
The ninety-day test. Come back to the harder question this article opened with. Over the last quarter, which decisions actually changed because of what your team wrote? A small team producing a handful of products that provably changed decisions is more mature than a large one producing forty documents a quarter that nobody acted on. If the list is short, the problem is usually the feedback loop rather than the analysis, which is also the last stage of the threat intelligence lifecycle and the one teams most often skip.
Where to Build the Skill
Report writing is the bottleneck skill in this field. Tools take weeks to learn. Analytical writing takes months of producing work, being wrong, getting corrected, and doing it again, which is why it is also the strongest signal on a job application. Hiring managers cannot see your reading. They can see your writing.
That is the gap CTI Academy's Hunter track is built to close. You work real investigations and then produce the assessment, which is where judgment actually forms. Our NullBase environment gives you a simulated underground to investigate, so you are writing about something you researched rather than something you read. LeakLens puts you inside credential and breach data. And the SOC, Phishing, and Attack Investigation simulators put you on the consuming end of intelligence, which is the fastest way to learn what a useful report feels like to the person receiving it. Start with the Hunter track.
Frequently Asked Questions
What is the BLUF method in threat intelligence reporting?
BLUF stands for Bottom Line Up Front. It means opening a report with your main conclusion and its significance in one or two sentences, rather than building toward it. The convention comes from US Army correspondence standards and was adopted by intelligence communities because decision-makers are often too busy to read a full product. Good BLUF writing also applies at paragraph level, with each paragraph opening with its own key point.
How do you write a threat intelligence report?
Start with a BLUF stating your assessment and recommendation. Separate what you observed from what you concluded. Use standardized probability and confidence language rather than vague hedges. Include specific impact on your organization and recommended actions with owners and deadlines. Put technical indicators in an appendix, and mark the document with the correct TLP label on every page.
What is the difference between probability and confidence in an intelligence assessment?
Probability describes how likely an event or outcome is, expressed with terms like "unlikely" or "very likely" mapped to numeric ranges. Confidence describes how much you trust your own judgment based on the quality of your evidence, usually expressed as high, moderate, or low. They are independent, so you can hold a high-confidence judgment that something is unlikely.
What are the words of estimative probability?
They are standardized terms that map to numeric likelihood ranges, so that different readers interpret them the same way. Under Intelligence Community Directive 203 the scale runs almost no chance (1 to 5 percent), very unlikely (5 to 20), unlikely (20 to 45), roughly even chance (45 to 55), likely (55 to 80), very likely (80 to 95), and almost certain (95 to 99).
Can you use a confidence level and a probability word in the same sentence?
No. Intelligence Community Directive 203 explicitly states that products expressing a confidence level must not combine that confidence level and a degree of likelihood in the same sentence, because it leaves the reader unable to tell what is being qualified. Write the probability judgment in one sentence and state your confidence and its basis in the next.
What should a threat intelligence report include?
A findable title with a date and TLP marking, a BLUF or key judgments section, a clear statement of what is known, an assessment that considers alternative explanations, the specific impact on your organization, recommended actions with owners and deadlines, and an appendix containing indicators, techniques mapped to MITRE ATT&CK, detection logic, and sources.
Why do threat intelligence reports get ignored?
Usually because they bury the conclusion, describe a threat without explaining what it means for the reader, forward external research without adding an assessment, or target the wrong audience. Reports written at the wrong altitude, such as technical indicator detail sent to executives, are among the most common and most wasteful failures.
Sources
- ICD 203: Analytic Standards, Office of the Director of National Intelligence
- Communicating Uncertainties in CTI Reporting, FIRST Cyber Threat Intelligence SIG
- Words of Estimative Probability and Analytic Confidences, Center for Internet Security
- The power of BLUF, Microsoft
- CTI Report Writing 101, Kraven Security
- The 10 Fallacies of Cyber Threat Intelligence, Filigran