Writing Threat Intelligence Reports: Structure, Confidence Language and Audience Craft

Most threat intelligence reports are not ignored because the analysis is wrong, they are ignored because the reader cannot find the judgment, cannot tell how sure the analyst is, or cannot see what to do. This guide covers the writing craft behind finished cyber threat intelligence (CTI): how to build a judgment, how to express likelihood and confidence without ambiguity, how to shape the same intelligence for executives, the SOC and sharing partners, and how to review drafts before release. It goes deeper than the form itself, which lives in the Threat Intelligence Report Template. It is written for CTI analysts, detection engineers who write advisories, and the leads who review and approve their work.

Key takeaways

• Write the judgment before the prose. If you cannot state the key judgment, its likelihood and the reader's action in three sentences, the report is not ready to draft.
• Likelihood and confidence are different claims. ICD 203 tells analysts not to combine a confidence level and a degree of likelihood in the same sentence, because one describes the event and the other describes the evidence.
• Use one fixed vocabulary. Pick a single probability scale (ICD 203 or the UK yardstick), publish it with the report and never invent new words such as "highly possible".
• Audience decides length, not topic. The same campaign becomes a one-paragraph risk statement for the board, a technique and detection pack for the SOC, and a sanitised TLP:GREEN note for an ISAC.
• Review is part of writing. A peer review against ICD 203's nine tradecraft standards catches blended facts and judgments, missing alternatives and actions with no owner.

What a finished intelligence report has to do

A report exists to change a decision. NIST SP 800-150 defines cyber threat information as any information that can help an organisation identify, assess, monitor and respond to cyber threats, which is a useful test: if a paragraph does not help the reader do one of those four things, cut it. ICD 203, the US Intelligence Community directive on analytic standards (signed 2 January 2015), sets five analytic standards that read well as a writing brief: analysis must be objective, independent of political consideration, timely, based on all available sources, and must implement the tradecraft standards.

Those nine tradecraft standards are the best single checklist for a CTI writer, and the rest of this guide is organised around them:

For how sources and confidence are graded in depth, see the Intelligence Confidence and Source Reliability Guide. This page focuses on turning those grades into sentences.

Structure: build the argument before the document

Experienced analysts draft in the reverse order to how the report is read. The structure below works for flash alerts and long assessments alike; only the depth of each part changes.

1. State the intelligence question. Write the requirement the report answers, for example "Is the campaign exploiting [VPN product] likely to target our sector this quarter?" A report with no question drifts into a news summary. See the Intelligence Requirements Template.
2. List the evidence and grade it. Separate what you observed in your own telemetry from what others reported. Note gaps now, not at the end.
3. Draft the key judgments. Each judgment is one sentence with one likelihood term, followed by a separate sentence on confidence and why.
4. Test alternatives. Write down at least one other explanation and the evidence that would make it true. If you cannot reject it, it stays in the report.
5. Write the actions. What should which team do, on what system, by when.
6. Write the bottom line up front (BLUF) last. Two to four sentences: what is happening, why it matters to this reader, the key judgment, and the single most important action.
7. Add the detail, sources and annexes. Technical depth goes after the reader already knows why it matters.

Paragraph discipline

• Topic sentence first: every paragraph opens with its conclusion. A reader skimming first sentences should get the whole argument.
• One judgment per paragraph: two judgments with different likelihoods in one paragraph invite readers to merge them.
• Evidence follows the claim: "We assess the group gained access through help desk impersonation. Two victims reported calls to IT support from a caller using an employee's name, and sign-in logs show MFA re-registration minutes later."
• Dates in UTC and absolute form: "on 4 November 2026 at 14:10 UTC", never "yesterday" or "last week", because reports are forwarded and re-read.

Headings that carry meaning

Prefer headings that state a finding ("Initial access came through the help desk") over labels ("Initial access"). The CISA joint advisory format is a good public reference: Summary, Technical Details, MITRE ATT&CK Tactics and Techniques, Mitigations, Validate Security Controls, Reporting, References and Version History. CISA advisory AA23-320A on Scattered Spider, for example, states the ATT&CK version it maps to and gives one table per tactic with columns for technique title, ID and how the actor used it.

Confidence language: likelihood, confidence and the words in between

Sherman Kent's essay "Words of Estimative Probability", published by the CIA, recounts how readers of a 1951 estimate understood "serious possibility" as anything from a low chance to a high one. His remedy, a fixed set of terms tied to odds, is still the basis of modern practice. ICD 203 publishes seven bands and strongly encourages analysts not to mix terms from different rows; if they do, the product must say the terms indicate the same probability.

Confidence is about the evidence

ICD 203 says products that use confidence levels must not combine a confidence level and a degree of likelihood in the same sentence. Write "We assess the group will likely target [sector] VPNs in Q1. We have moderate confidence in this assessment because it rests on one vendor report and our own scanning data, and we have no insight into the group's planning." Avoid "highly likely with high confidence".

The MISP estimative-language taxonomy, based on ICD 203 and US Joint Publication 2-0, gives practical definitions that make confidence levels consistent across analysts:

Words to retire

• "Possibly", "could", "may": technically true of almost anything. Kent reserved an unmodified "possible" for outcomes whose odds cannot be judged at all. If you can estimate the odds, use a band.
• "Reportedly", "appears to": Kent criticised these for hiding the writer's own view. Say who reported it and how much you believe it.
• "Sophisticated", "advanced": describe what the actor did instead ("used valid VPN credentials and a signed driver").
• "Nation-state" without a basis: attribution is itself a judgment and needs its own likelihood, confidence and alternatives.

UK and allied scales

UK government assessment, including NCSC reporting, uses the Professional Head of Intelligence Assessment (PHIA) probability yardstick, whose bands and terms differ from ICD 203 and deliberately leave gaps between ranges. If your readers include UK public sector or allied partners, choose one scale, name it in the report footer and do not mix the two. Whatever scale you use, put a small key at the end of every report so a forwarded copy still explains itself.

Writing for each audience

One piece of intelligence usually produces several products. Write the technical analysis once, then derive the others, rather than writing a long report and hoping each reader finds their part.

Executive writing

Executives read the first paragraph and the decision box. Translate technique into consequence: "an attacker who calls our IT help desk could reset an employee's MFA and reach payroll" is more useful than "T1566.004 Spearphishing Voice leading to T1621 Multi-Factor Authentication Request Generation". Give one comparison they understand (exposure this quarter versus last) and one ask. For board formats, see the Board Cyber Report Template.

Technical writing

For the SOC, precision beats prose. Give each ATT&CK technique with its ID and the specific procedure observed, the data source that would show it, and a link to the Sigma or SIEM rule rather than a pasted query. CISA's "Best Practices for MITRE ATT&CK Mapping" (first published June 2021, updated January 2023) warns analysts about analytical biases and mapping mistakes; the practical rule is to map only behaviour you have evidence for, at the most specific level the evidence supports, and to state the ATT&CK version. See the Sigma Rules Guide.

Identity detail is often the actionable part

Many current intrusions run on stolen credentials, tokens and API keys as well as malware, which ATT&CK records as T1078 Valid Accounts. Reports should name the identity type involved (workforce account, service account, OAuth app, CI/CD token) and the revocation action, because that is what responders act on first. See the Threat Intelligence for Identity and NHI Guide.

Sharing, marking and sanitising

• Mark before writing: decide the Traffic Light Protocol label at the start, because it shapes what you can include. FIRST TLP 2.0 has been authoritative since August 2022 and defines TLP:RED, TLP:AMBER, TLP:AMBER+STRICT, TLP:GREEN and TLP:CLEAR. See the Traffic Light Protocol Guide.
• Place labels where they survive forwarding: TLP 2.0 says documents carry the label in the header and footer of every page, and messages carry it in the subject line and directly before the information. Labels are written in capitals without spaces and are not translated.
• Write the sanitised version deliberately: remove victim and customer names, internal hostnames and IP ranges, user names, and details of your own control gaps. Keep the techniques, timings and indicators that help partners. Have a second person check it against the original.
• Machine-readable twin: publish indicators and techniques as a STIX 2.1 bundle or CSV annex rather than inside prose, so tools can ingest them and readers can skip them. See the STIX and TAXII Guide.
• Indicators need context: type, value, first and last seen, source grade and an expiry date. Prefer behaviours over hashes where possible. See the Pyramid of Pain Guide.

Review and release workflow

Peer review is where most quality comes from. Treat it as a short, structured check rather than a proofread.

1. Author self-check (10 minutes): read only the BLUF and the first sentence of each paragraph. Does that alone carry the argument? Is every likelihood term from the agreed scale?
2. Peer review (analyst, 20 to 40 minutes): challenge each key judgment: what would have to be true for it to be wrong? Check that facts and judgments are separated, alternatives are stated, and every technique ID and indicator is correct. See the Structured Analytic Techniques for CTI Guide.
3. Consumer check (optional, for high-impact reports): ask one SOC lead or system owner whether they would know what to do after reading it.
4. Approval: CTI lead confirms TLP, distribution list and that actions have owners.
5. Release and route actions: actions go to tickets with owners, not just to an email list.
6. Update, never silently edit: issue a new version that states what changed and whether any judgment changed, as tradecraft standard 7 requires.
7. Roll back a bad report: if a judgment proves wrong, issue a correction at the same TLP to the same distribution, say what was wrong and withdraw indicators that should not be blocked.

Choosing the product: quick decision guide

• Flash alert: active exploitation of something you run, or credible targeting of you. One page, released within hours, accepting lower confidence and saying so.
• Incident intelligence report: a declared incident needs actor or technique context. Updated as the incident runs.
• Assessment: answers a standing intelligence requirement. Slower, more alternatives, higher confidence bar.
• Small teams: one analyst can still apply all of this. Keep a one-page style guide (scale, TLP, template) and use a colleague from the SOC as peer reviewer. Large teams add a dedicated editor role and a quarterly calibration session.

Measuring whether your reports work

Calibration is the subtle one: if judgments marked "likely" (55 to 80%) come true 95% of the time, analysts are under-claiming, and readers will learn to discount the words. Track it over a year of judgments, not a month.

Framework mapping

Common failure patterns

• The news summary BLUF: the opening restates a vendor blog ("A new ransomware strain has emerged") instead of the impact on the reader ("Two of our file servers run the targeted version").
• Blended certainty: "highly likely, high confidence" in one breath, or a different probability word in every paragraph, so readers cannot compare judgments.
• Attribution as decoration: naming a group in the title on thin evidence. Attribution rarely changes the defensive action; when you include it, give it its own likelihood, confidence and alternatives. See the Scattered Spider Threat Actor Profile for how overlapping vendor names complicate this.
• Indicator dumps: hundreds of hashes and IP addresses with no dates, source grades or expiry, pasted into the body where nobody reads them and tools cannot parse them.
• Actions with no owner: "organisations should patch" in an internal report. Every action needs a team, a system and a date.
• Silent edits: correcting a published report in place, so earlier readers act on the old judgment and nobody knows it changed.

Practitioner checklist

• Write the intelligence question and the reader's decision before drafting.
• Adopt one probability scale, publish it in the style guide and add a key to every report.
• State likelihood and confidence in separate sentences, with the reason for the confidence level.
• Start judgments with "We assess" and state facts plainly; list key assumptions.
• Record at least one alternative explanation and why it was rejected or kept.
• Write the BLUF last and test that it stands alone.
• Derive audience versions from one technical analysis; sanitise sharing versions with a second check.
• Apply TLP 2.0 labels in headers, footers and subject lines; put indicators in a machine-readable annex with expiry dates.
• Peer review every non-flash report against the ICD 203 tradecraft standards.
• Track action completion, feedback and judgment accuracy, and run a calibration session at least once a year.

Standards and references

• Office of the Director of National Intelligence: Intelligence Community Directive 203, Analytic Standards
• CIA Center for the Study of Intelligence: Words of Estimative Probability (Sherman Kent)
• FIRST: Traffic Light Protocol (TLP) 2.0
• NIST: SP 800-150 Guide to Cyber Threat Information Sharing
• CISA: Best Practices for MITRE ATT&CK Mapping
• CISA: Advisory AA23-320A, Scattered Spider (example advisory structure)
• MISP Project: Estimative Language Taxonomy
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Threat Intelligence Report Template · Threat Intelligence Guide · Intelligence Confidence and Source Reliability Guide · Structured Analytic Techniques for CTI Guide · Threat Intelligence Analyst Career Guide