OSINT Report Template for a Defensible Investigation

Collection is minutes per source. Turning collection into a document a non-technical stakeholder can act on is hours, every case, and it is usually done by the most expensive person on the team. The structure below removes most of that time by deciding the shape once instead of every case.

It is written for investigations built on public records: vendor due diligence, own-estate review, acquisition checks, brand and lookalike work. Every section says what it is for, because a template you follow without knowing why produces documents that look right and defend nothing.

1. Scope header, written before collection

The first block of the report, and chronologically the first thing that exists. Six fields:

The ordering is the whole point. A scope written before collection constrains what you do and reads as a decision. A scope written afterwards is a justification and reads as one. Anybody reviewing a file can tell which they are looking at.

2. Summary, written for the person who reads nothing else

One paragraph, four to six sentences. What was assessed, what matters, what you recommend, and how confident you are. No jargon, no findings dump, no build-up. Assume it is read on a phone by somebody who has to make a decision this afternoon.

3. Findings, one structure repeated

Every finding is the same five parts, in the same order, without exception. Consistency is what lets a reviewer scan forty findings without re-learning the layout each time.

1. Severity or materiality. A small closed set. High, medium, informational, pass. Defined once at the front of the report so the words mean the same thing in every case your team writes.
2. The claim. One sentence, plain, active. "The domain publishes no DMARC policy," not "DMARC was investigated."
3. The evidence. The raw record exactly as returned, quoted, not paraphrased and not screenshotted.
4. The source. The endpoint or system that answered, specific enough to re-run.
5. The retrieval time. Full UTC, ISO 8601, on every finding.

Worked example, in the form the domain footprint sweep emits:

A reviewer can re-run that in ten seconds and either agree or not. That is the standard. Anything a reviewer cannot re-run is an assertion wearing the clothes of a finding.

4. Negative findings, in their own section

What you looked for and did not find belongs in the report, dated exactly like everything else. Two reasons, both practical.

• It shows the boundary of the work. A reader knows what was checked, so they know what silence means.
• It protects you. "No adverse registry filings were found at the time of retrieval" is a defensible statement about your collection. "There are none" is a claim about the world that you cannot support.

5. Confidence and limitations, stated in plain words

Say what would change your conclusion. Redacted registration data, a jurisdiction whose registry is not public, a certificate log that only proves issuance rather than deployment, an aggregator you could not independently corroborate. A limitations section makes a report more credible rather than less, because it demonstrates you know where your own evidence thins out.

Use a small, defined confidence vocabulary and apply it per finding, not per report. High confidence from a direct record. Medium from a single indirect indicator. Low from a weak pivot such as shared cloud infrastructure. The techniques post goes through which pivots deserve which grade.

6. Method and reproducibility appendix

Which modules ran, which sources were queried, what was deliberately not done, and the full collection window in UTC. Short, factual, and the section that turns a document into something a second analyst can reproduce in a quarter to produce a diff.

7. What does not belong in the report

• Screenshots as primary evidence. No retrieval timestamp, no source endpoint, trivially croppable. Quote the record.
• Speculation about individuals. If it is about a named person and you have no lawful basis, it does not go in, and mostly it should not have been collected. See our acceptable use boundary.
• Tool narration. Nobody needs to know which tab you had open. They need the record and the time.
• Undated claims of any kind. If it has no timestamp it is not a finding yet.
• Severity inflation. Marking everything high destroys the signal you are being paid to provide.

Why this is worth automating

A risk team screening 120 vendors a year at three and a half hours of write-up per vendor spends 420 hours turning findings into documents. At a loaded cost of $85 an hour that is roughly $35,700 a year, spent on formatting rather than on judgment. The arithmetic is stated so you can challenge it with your own numbers on the third-party risk page.

The structure above is exactly what Osintpro emits natively: the scope header from the declaration you made before collection, findings already carrying their record, endpoint and UTC timestamp, and negative findings kept rather than dropped. The template is free to use whether or not you ever use the product. Take it and put it in your team wiki.