A threat intelligence report has one job: help someone make a better decision than they would have made without it. Many reports fail that test, and the research behind them is usually not the problem. The problem is what happens on the page — the judgment gets buried, the attribution gets hedged into meaninglessness, and the recommendations read like a policy poster. These failures are structural, which is good news. They show up in the same places, and a disciplined edit removes most of them.

Attribution That Says Nothing

Consider a line that appears in far too many finished products:

The activity may be linked to a sophisticated, state-sponsored adversary, possibly with espionage intent.

Read it again and count what it actually tells the reader. Not the actor, not the evidence, not even the direction of the analysis. "May be linked" is a shrug dressed as a finding, and "sophisticated" is flattery, not intelligence.

You have two honest options. Name the cluster you track and say why the link holds — shared infrastructure, tooling reuse, victimology, timing that matches a known operational pattern. Or state plainly that the activity is unattributed and describe what you can support: capability, targeting, observed tradecraft. Both are useful. The hedge is not.

Separate four things that analysts habitually blend: the actor, the campaign, the malware family, and the infrastructure. A shared IP address links infrastructure. It does not link a government. Write at the level your evidence supports, then say what would change your assessment.

Confidence Levels That Carry No Information

Slapping "high confidence" on every judgment is the same as writing nothing. So is the opposite habit: burying a solid finding under "may, could, possibly" until the reader gives up.

Attach confidence to a judgment, not to a document

Confidence is a property of a specific claim. "We assess with moderate confidence that the operators gained initial access through the public VPN appliance" means something. A header reading "Confidence: High" over an eight-page report means nothing, because it cannot tell you which parts to trust and which to treat as working theory.

Define the scale in the report

Readers cannot calibrate a term they have never seen defined. Add a short note that states what your labels mean, and make the underlying logic visible:

• How many independent sources support the judgment, and are any of them first-hand?
• Is it corroborated by your own telemetry, or only by third-party reporting?
• How fresh is the evidence, and does it still hold for current activity?
• Does it fit historical patterns, or contradict them?

Then use language that matches. High confidence should be rare enough to matter. If every judgment is high confidence, none of them are.

Indicator Lists Without Context or Shelf Life

A wall of IP addresses is not intelligence. It is a lead-generation exercise for your ticketing system. Blocklists rot quickly, especially addresses tied to short-lived infrastructure, and generic hosting ranges generate alerts that trained analysts learn to close without reading.

Give every indicator three things: what it is, when it was observed, and what it means. An address that returned a payload config is not the same as one that scanned a single port, and treating them alike wastes response capacity. Add a validity window and say when the list was last reviewed. Where possible, pair atomic indicators with behavioural detections — the registry key, the parent-child process relationship, the unusual authentication pattern — because behaviour survives infrastructure rotation. And mark what you consider high-fidelity. Ten indicators an analyst trusts beat a thousand they ignore.

Recommendations No One Can Act On

"Organisations should patch systems and raise awareness among employees" is not a recommendation. It is a bumper sticker. The test is simple: can a named person, on a known team, do this on Monday and tell you afterwards whether it worked?

Use a consistent structure for each recommendation:

1. Action: the specific change — a detection rule, a configuration setting, a hunt query.
2. Owner: the team accountable for doing it, not "the organisation".
3. Priority and trigger: do it now, or do it if the indicator appears in your environment.
4. Verification: how the reader confirms it is done, and how they confirm it works.
5. Escalation: what to do if the activity is found — who to call, what to preserve.

Rewrite the vague line and it becomes usable: "Internet-facing VPN appliances should be inventoried and checked against the vendor advisory by the endpoint team this week; report unpatched instances to the security lead." Same intent, entirely different outcome.

Writing for the Wrong Reader

Many reports are written for the analyst's peer group, then handed to people with different questions. The result is a document that is too technical for decision-makers and too thin for engineers.

Front-load the judgment. A short block of key findings at the top — what happened, why it matters to us, what we are doing about it — serves everyone. Keep the technical annex separate and label it clearly. Define acronyms on first use, and do not lean on framework identifiers as a substitute for explanation; a reader who has to look up a technique code has lost the thread. Fluency with MITRE ATT&CK is valuable. Plain language is mandatory.

Sourcing, Dates, and Version Control

Readers make trust decisions based on where your information came from. Distinguish your own collection from vendor reporting and from open-source claims, and cite sources the reader can check. Date every observation, not just the report. State the handling caveat so recipients know the sharing boundary, and version the document with a short change log when you revise it. Corrections issued quietly in a new file are how organisations end up working from two different versions of the same assessment.

The Edit That Catches Most of It

Before you send the next report, read the draft once with a pen and ask four questions. Does every attribution claim name an actor or admit it cannot? Does every judgment carry its own confidence? Can a specific team act on each recommendation? Are the sources and dates visible? Where the answer is no, cut or rewrite. The report will get shorter, and it will get better.

Photo: AS_Photography / Pixabay