Writing intelligence reports

Analysis that nobody reads did not happen. Writing is the deliverable, and it is the skill most under-practised by candidates who came in through a technical route.

BLUF

Bottom Line Up Front. The first paragraph states the judgement and what should be done about it. Not the background, not the methodology, not a chronology of your investigation.

Compare:

Weak. "On 14 March, our SOC observed anomalous authentication activity. Following investigation, several indicators were identified. Analysis of these indicators revealed connections to previously reported infrastructure. This report details our findings."

Better. "An intrusion set very likely obtained valid credentials for three engineering accounts and retained access for at least eleven days. We assess with moderate confidence that data staging occurred but exfiltration did not complete. The immediate decision is whether to force a tenant-wide credential reset this week, which we recommend; the residual risk of not doing so is continued access through tokens we cannot enumerate."

The second version front-loads the judgement, carries calibrated language, and names the decision. That is the whole difference, and it is learnable.

Separate observation from assessment

The single most valuable habit. Your reader must be able to tell, at a glance, which sentences are things you saw and which are things you concluded.

• Observation: "The binary created a scheduled task named MicrosoftEdgeUpdateTaskMachineUA executing from %APPDATA%."
• Assessment: "The task name imitates a legitimate updater, which we assess is intended to survive casual review of scheduled tasks."
• Gap: "We do not know how the binary was delivered; endpoint logging on the host began after the compromise window."

Stating gaps explicitly reads as confidence, not weakness. Analysts who hide gaps get caught by the first person who asks a follow-up question.

Write for a named audience

The most common failure is writing at the tactical altitude for a strategic reader — a list of indicators sent to a CFO. The second most common is the reverse: vague "elevated threat environment" language sent to engineers who needed a query.

A structure that works

1. Key judgements — two to four bullets, each with an estimative term and a confidence level.
2. So what — impact on this organisation specifically, and the decision on the table.
3. What we observed — evidence, sourced and graded.
4. Analysis — reasoning, alternative hypotheses considered and why they rank lower.
5. Gaps and collection needs — what you do not know and what would resolve it.
6. Recommendations — specific, owned, and within the reader's authority to act on.
7. Appendix — indicators, ATT&CK mappings, technical detail. Never in the body.

Habits that mark an experienced analyst

• Date your judgements. "As of 2 April" — assessments decay.
• Recommend things the reader controls. "Patch the edge appliance" is actionable; "improve security culture" is not.
• Give indicators of change. What would make you revise this?
• Mark handling clearly — see TLP. Getting this wrong damages sharing relationships permanently.
• Cut the adjectives. "Sophisticated", "advanced" and "highly targeted" usually replace a specific description that would have been more useful.
• Own the correction. When an assessment turns out wrong, reissue it plainly. This builds more credibility than being right did.