Skip to main content

OSINT Report Template: How to Write Findings Other Analysts Can Check

A complete, copy-and-use OSINT report template with scope, lawful basis, method, graded findings, a source log, confidence language and limitations, plus two worked reports: supplier due diligence and a refund-abuse case.

· By UserSearch Team · 16 min read

Disclaimer: This article is for education and for lawful, authorised professional research. Use these methods only where you have a legitimate purpose and a lawful basis, and follow the laws and platform terms that apply to you, including data protection law such as the UK GDPR and EU GDPR. See our Terms of Service.

TL;DR

  • Whatever OSINT report template you use, the report is only as good as a second analyst's ability to repeat it. If a colleague cannot rerun your searches and reach the same finding, the report is an opinion.
  • Below is a complete, copy-and-use report template: header, scope and lawful basis, the question, method, graded findings with a source log, confidence language, limitations and an appendix of exported search results.
  • We use the UK probability yardstick for likelihood words and a separate confidence rating, so readers never confuse "how likely" with "how sure".
  • Two worked reports show the template in use: a supplier due-diligence check and a refund-abuse report for a payments team.
  • UserSearch Cases, OneScan source attribution and exports give you the source log and appendix without rebuilding them by hand.

Why Do Most OSINT Reports Fail the Second Reader?

An OSINT report template is a fixed structure for writing up open-source research so that every finding carries its source, its date, its grade and its method, and another analyst can check it. Most OSINT reports we are asked to review share the same flaw. The research was fine. The write-up was not. A paragraph says "the director is linked to three other companies", a screenshot sits underneath, and nothing tells the reader which register was searched, on what date, with what spelling of the name, or why the analyst believes the match is the same person rather than a namesake.

That report works for exactly one reader: the person who wrote it, on the day they wrote it. Hand it to a compliance manager six months later, or to an outside solicitor, and it collapses under the first question. Where did this come from? Can I see it? What did you check that came back empty?

The fix is not more research. It is structure. A good report separates what a source said from what you concluded, grades both, records the method well enough to repeat, and admits what you did not look at. This guide gives you a template that does all of that, explains every block, and walks through two complete examples.

What Does an OSINT Report Actually Have to Do?

An OSINT report is a written record of research on publicly and commercially available information, produced so that a decision-maker can act on it and another analyst can check it. That second half is the part most templates skip. The Berkeley Protocol on Digital Open Source Investigations, published by the UN Human Rights Office with UC Berkeley, sets the bar well: collection, preservation, verification and analysis should each be documented so the work can be relied on later by people who were not in the room.

Government analysts have worked to a similar standard for years. The US Intelligence Community Directive 203 on analytic standards lists tradecraft standards that translate well to commercial work. Three matter most for us: describe the quality and credibility of the underlying sources, express and explain uncertainty, and distinguish clearly between the underlying information and the analyst's own assumptions and judgments. If your report does those three things, it is already better than most.

So in practice, a checkable report has four jobs:

  • Answer a stated question, not wander through everything that turned up.
  • Show the route: which sources, which inputs, which dates, which filters.
  • Grade what was found, both the source and the claim, and say how confident you are in the overall judgment.
  • Preserve the evidence so the finding survives the page being edited or deleted next week.

Why Checkable Reporting Matters More in 2025 and 2026

Two UK changes have pushed OSINT reports out of the analyst's notebook and into the compliance file.

First, the corporate offence of failure to prevent fraud came into force on 1 September 2025. The Home Office guidance to organisations on the new offence names due diligence as one of six principles for reasonable procedures, applied in a proportionate, risk-based way to people who provide services for or on behalf of the organisation. If your defence is "we had reasonable procedures", you will need written evidence of the checks you ran on agents and suppliers. A report nobody can reproduce is weak evidence of a procedure.

Second, Companies House began mandatory identity verification for directors and people with significant control on 18 November 2025, as confirmed in its rollout announcement. That improves the register, but it also means an officer record may look different depending on whether you searched it before or after an individual verified. Dates of search now matter more, not less. A report that says "Companies House shows..." without a search date is already ambiguous.

Insurers, payments teams and claims handlers feel this most, because their reports feed decisions that get challenged: declined claims, closed accounts, withheld payouts. That is why our insurance and fraud teams page focuses on repeatable, attributed research rather than one-off lookups.

The Copy-and-Use OSINT Report Template

Copy the block below into your case notes or document system. Every heading is there for a reason, and we explain each one after the template. Keep the order. Readers learn where to look, and reviewers can compare reports side by side.

OSINT RESEARCH REPORT
======================================================================
1. HEADER
Report reference:      OR-2026-0142
Version:               v1.0 (draft) | v1.1 (peer reviewed) | v2.0 (final)
Author:                [analyst name, team]
Peer reviewer:         [name] | Review date: YYYY-MM-DD
Requested by:          [name, role, team]
Date range of work:    YYYY-MM-DD to YYYY-MM-DD (all times UTC)
Handling:              Internal. Contains personal data. Share on a
                       need-to-know basis. Retain until YYYY-MM-DD.
Case ID in platform:   [UserSearch Case name / ID]

2. SCOPE AND LAWFUL BASIS
Purpose:               [e.g. supplier onboarding due diligence]
Lawful basis:          [e.g. UK GDPR Art. 6(1)(f) legitimate interests;
                        LIA reference LIA-2026-017]
In scope:              [entities, identifiers, time window]
Out of scope:          [what you agreed not to research, e.g. personal
                        life, private accounts, personal finances]
Proportionality note:  [why this depth of research fits the risk]

3. THE QUESTION
Primary question:      [one sentence the report must answer]
Sub-questions:         a) ...  b) ...  c) ...
Decision it supports:  [e.g. approve / reject / escalate onboarding]

4. METHOD
Starting identifiers:  [company number, domain, email, username ...]
Sources searched:      [register, platform, Search type, Module]
Tools and versions:    [e.g. maigret 0.5.x, waybackpy 3.0.x]
Search settings:       [exact input strings, filters, date ranges]
Negative checks:       [sources searched that returned nothing]
Deviations:            [anything done differently from standard SOP]

5. BOTTOM LINE (KEY JUDGMENTS)
KJ1: [judgment] -- Likelihood: [yardstick term] -- Confidence: [H/M/L]
KJ2: ...

6. GRADED FINDINGS
ID | Finding (what the source says) | Source ref | Source grade |
   | Info grade | Corroborated by | Analyst comment
F1 | ...                            | S03        | B            |
   | 2          | S05, S07        | ...

7. SOURCE LOG
Ref | Source / URL | Accessed (UTC) | Input used | Capture file |
    | SHA-256 | Archive URL
S01 | ...

8. ASSUMPTIONS AND ALTERNATIVE EXPLANATIONS
A1: [assumption the judgments rely on]
ALT1: [other explanation considered, and why it was rejected or kept]

9. LIMITATIONS
- Coverage gaps (sources not available, regions not covered)
- Freshness (dates of the newest data per source)
- Access limits (rate limits, login-only content not reviewed)
- Matching risk (common names, shared handles, recycled numbers)

10. RECOMMENDATIONS / NEXT STEPS
- [action], owner, date

APPENDIX A: Exported search results (CSV/PDF), file names and hashes
APPENDIX B: Captures and archive links
APPENDIX C: Change log for this report

Header and Handling Block

The header answers "who, when, which version" before a reader reaches a single finding. Two fields earn their place more than people expect. The peer reviewer field forces a second pair of eyes before the report goes out, and the retention date forces you to decide, at the start, how long the personal data inside it will be kept. Put the platform Case ID here too, so a colleague can open the full search history behind the document.

Scope, Lawful Basis and the Question

Write the question before you search, not after. "Is Supplier A a genuine, trading business controlled by the people it names in its onboarding form?" is answerable. "Find out about Supplier A" is not, and it invites scope creep into areas you have no basis to research. The out-of-scope line is where you record the limits you agreed with the requester. When a reviewer later asks why you did not look at a director's personal life, the answer is already written down.

Method and the Source Log

The method section describes the route in general terms. The source log is the line-by-line evidence: one row per source, with the access time in UTC, the exact input string, the capture file and its SHA-256 fingerprint. Record negative checks too. "Searched the register for the trading name, no match" is a finding, and often an important one.

Graded Findings and Confidence Language

Each finding carries two grades: one for the source's reliability (A to F) and one for the credibility of the specific claim (1 to 6), in the style of the Admiralty system that many police and military analysts use. Keep them separate. A company register is a reliable source, but a director's self-declared occupation on it is still only what they chose to write.

For judgments, use two separate scales. Likelihood says how probable something is. Confidence says how solid the foundations of that judgment are. The UK Professional Head of Intelligence Assessment publishes both in its guidance on explaining uncertainty in UK intelligence assessment, updated in March 2025. We use its probability yardstick as written:

TermApproximate probabilityExample sentence in a report
Remote chanceabout 0 to 5%There is a remote chance the two accounts belong to different operators.
Highly unlikelyabout 10 to 20%It is highly unlikely the domain was registered by an unrelated party.
Unlikelyabout 25 to 35%It is unlikely the company trades from the listed premises.
Realistic possibilityabout 40 to under 50%There is a realistic possibility the director holds other undeclared roles.
Likely or probableabout 55 to 75%The handle is likely operated by the same team as the domain.
Highly likelyabout 80 to 90%It is highly likely the website was created after the company was incorporated.
Almost certainabout 95% and aboveIt is almost certain the invoice email domain is not controlled by the supplier.

Leave the gaps between the ranges alone. They exist so analysts do not argue over whether 52% is "realistic possibility" or "likely". Then add High, Moderate or Low confidence, based on the quality of the sources, the rigour of your method and how fast the facts are changing. "Likely, low confidence" is a perfectly honest judgment. Burying it under "appears to" is not.

Limitations and the Exported Appendix

Limitations are not an apology. They tell the reader where the edges of the research are: which sources you could not reach, how fresh each dataset was, and where name-matching risk remains. The appendix holds the exported search results as files, each with its hash, so the report body can stay short while the evidence stays complete.

How Do You Build the Evidence Trail by Hand?

You can produce a checkable report with free tools. It just takes discipline. Here is the manual route we see most often, with the friction you should expect.

Fingerprint Every Capture

Save each page as a PDF or PNG, then record a SHA-256 hash so any later change to the file is detectable.

sha256sum captures/S03_register_officers_2026-09-18T1012Z.pdf
# macOS equivalent
shasum -a 256 captures/S03_register_officers_2026-09-18T1012Z.pdf

sha256sum prints a 64-character hex digest followed by the file name. Paste the digest into the source log row. On macOS, shasum -a 256 selects the SHA-256 algorithm; the default is SHA-1, which you should not use for evidence. Name files with the source reference and a UTC timestamp so they sort in collection order.

Ask a Public Archive for an Independent Copy

A local capture proves what you saw. An archive copy made by a third party helps a sceptical reader believe it. You can submit a page through the Internet Archive's Save Page Now form, or script it with waybackpy, a Python client for the Wayback Machine APIs. No API key is needed.

pip install waybackpy
waybackpy --url "https://supplier-a.example.com/about" --user_agent "orrington-research-team" --save
waybackpy --url "https://supplier-a.example.com/about" --user_agent "orrington-research-team" --oldest

--url is the page to archive, --user_agent identifies your client (use something honest and consistent), --save requests a fresh snapshot and --oldest returns the earliest snapshot on record, which is useful for establishing when a website first appeared. Expect friction. Save requests are throttled, some sites refuse the archive crawler, and the project has not shipped a release in a while, so check it still works before you depend on it in a live case.

Archive Social Posts in Bulk

For many social posts and videos at once, Bellingcat's open-source Auto Archiver reads URLs from a spreadsheet or the command line and saves the content locally or to cloud storage.

pip install auto-archiver
auto-archiver --help

It needs a YAML configuration file before it does anything useful, and some platforms need login cookies or API keys to archive reliably. Budget an afternoon for setup. Once it runs, it writes back a status report per URL, which slots neatly into Appendix B.

Where the Manual Route Breaks

The tools are fine. The weak point is the join between them. Search results live in browser tabs, captures live in a downloads folder, hashes live in a spreadsheet and the narrative lives in a Word file. Every copy-and-paste is a chance to attach the wrong capture to the wrong finding, and nothing records the searches that returned nothing.

Producing the Same Report Inside UserSearch

We built UserSearch so the source log writes itself while you research. Open a Case in Forensic Mode before you start and the platform stores your search history and bookmarks inside that Case. That history is your method section and your negative checks, already dated. Private mode exists for exploratory work you do not want stored, so decide at the start which mode fits the job, and note it in the header.

When you need breadth, OneScan runs one input across several data sources you select and merges the results with source attribution on every item. The Credit cost is shown before you run it. Source attribution is exactly what the graded findings table needs: you know which provider said what, so you can grade the source rather than the platform. Through one UserSearch account you reach 100+ third-party data sources, which means fewer separate logins and fewer places your source log can go stale.

For page captures, Forensic Capture is our free browser extension. It takes full-page captures, records SHA-256 fingerprints and two independent timestamps (an RFC 3161 time-stamp token and OpenTimestamps), keeps a hash-chained notebook per case, and exports an evidence bundle with an offline verifier. That covers Appendix B without the spreadsheet.

SargeBot, the AI research assistant inside the platform, can draft a PDF report from an objective you set and the entity searches it builds. Treat its draft as a starting point: every finding still needs your grading, your source reference and your judgment, because AI output must be verified by the analyst who signs the report. If you are new to the platform, our beginner's guide to UserSearch OSINT covers Cases and search types step by step.

Worked Scenario: Supplier Due Diligence for a Logistics Contract

Context. A UK retailer, Orrington Retail (fictional), is about to appoint Stenbury Freight Ltd (fictional, company number 00000000) as a customs agent. Procurement asks one question: is Stenbury a genuine trading business controlled by the two directors named on its onboarding form? The lawful basis is legitimate interests, with an assessment on file, and scope excludes the directors' families and personal finances.

Actions. The analyst opens a Case in Forensic Mode and runs Corporate Intelligence on the company number, then Domain Intelligence on stenbury-freight.example.com, the domain in the supplier's email signature. OneScan on the invoice email address [email protected] checks where else it appears. Key pages go through Forensic Capture.

The findings table, abbreviated:

IDFindingSourceGradeComment
F1Company incorporated 2019, two directors match the onboarding formS01 company registerA2Official register; officer details are self-declared
F2Domain registered in March 2026, five months before the tenderS02 domain historyB1Two independent records agree on the creation date
F3Earliest archived copy of the website dates from April 2026S03 web archiveB2Consistent with F2
F4Accounts filed as dormant for 2024S01 company registerA2Conflicts with the "five years of trading" claim in the tender
F5Invoice email not found on any other business listingS04 OneScan exportC3Negative result; coverage limited

Outcome. Key judgment: "It is likely (moderate confidence) that Stenbury has not traded at the scale it describes; the company is real and the directors match, but its web presence is recent and its latest accounts are dormant." The recommendation is to escalate, not reject: ask the supplier for trading evidence and references. The procurement lead gets one page of bottom line; the audit file gets the full report with the Case ID and hashes. When an auditor asks eight months later why onboarding was delayed, the answer takes five minutes to find.

Worked Scenario: A Refund-Abuse Report for a Payments Team

Context. An online marketplace's payments team sees 41 refund claims in six weeks from accounts that each claim non-delivery. The team lead asks: are these claims coordinated by one group, and if so, which accounts and identifiers belong to it? The lawful basis is legitimate interests in preventing loss, and the research stays on the marketplace's own data plus open sources linked to the claimant identifiers.

Actions. Internal data gives the analyst the claimant emails, usernames and payout wallet addresses. Using bulk search, they run five emails at a time through Email Intelligence and the usernames through Username Intelligence. Three payout addresses go through the Cryptocurrency search type. Everything runs inside a shared Case so a second analyst on the team can review the search history.

Outcome. The report groups 29 of the 41 claims into one cluster. The strongest link is a shared payout wallet (A1: the marketplace's own ledger, confirmed by the public blockchain record). Weaker links are graded honestly: 11 accounts share a username pattern, @example_handle01 to @example_handle11, graded C3, because sequential handles can be coincidence. The key judgment reads "highly likely (high confidence) that at least 17 claims are coordinated; realistic possibility (low confidence) that the remaining 12 in the cluster are linked." The payments team acts on the 17 and sends the 12 for manual review. That split is only possible because the report separated strong from weak evidence instead of presenting one tidy number. Our OSINT fundamentals knowledge base has more on corroboration if your team is new to grading.

Advanced Reporting Patterns Worth Adopting

Report the Searches That Found Nothing

A negative result is a finding with a date and a coverage limit. "No adverse media found" means little on its own. "No results for the company name and both directors' names across the sources listed in S06 to S09, searched 2026-09-18" tells the reader exactly how far the claim goes.

Write the Alternative Explanation Down

For each key judgment, record at least one other explanation and why you rejected it. In the supplier case, "the company recently rebranded and the old website is on a different domain" is a real alternative. It was rejected because the register shows no previous name. Writing it down shows the reviewer you considered it.

Version the Report, Never Overwrite It

Draft, peer reviewed and final are different documents. Keep all three and add a change log in Appendix C. If a finding changes grade after new evidence arrives, the log shows when and why. Reports that silently change are the ones that get picked apart later.

Run a Two-Minute Reviewer Check

Before sign-off, the reviewer picks two findings at random and reruns them from the source log alone. If they cannot, the report goes back. It is the cheapest quality control we know.

Reports concentrate personal data, which makes them the riskiest artefact in the whole process. Apply data minimisation to the document, not just the research: include only the identifiers needed to support a finding, and redact the rest in versions shared outside the core team. Set the retention date in the header and honour it. The ICO's guidance on the storage limitation principle is clear that you must be able to justify how long you keep personal data, and a report kept "just in case" is hard to justify.

Stay inside the scope you wrote in section 2. Research the business questions you were asked, rely on information that is publicly or lawfully available, and respect the terms of the platforms you use. Describe people factually and neutrally in findings; a report is not the place for adjectives. Where a finding could lead to a decision about an individual, such as closing an account, make sure the grading and confidence make the uncertainty visible to the decision-maker. And remember that search results are leads to corroborate, not facts: coverage and freshness vary by source, which is exactly why the limitations section exists.

Frequently Asked Questions About OSINT Report Templates

What is an OSINT report template?

An OSINT report template is a fixed structure for writing up open-source research. It sets out a header, scope and lawful basis, the question, the method, graded findings, a source log, assumptions, limitations and next steps, so that every report records where each finding came from and another analyst can repeat the work and reach the same result.

What should an OSINT report template include?

A checkable OSINT report template should include the question the report answers, the method used, graded findings that separate what a source said from what the analyst concluded, a source log with access times, input strings and SHA-256 fingerprints of captures, the negative checks that returned nothing, stated limitations, and an appendix of exported search results.

How do you grade sources in an OSINT report?

In an OSINT report, each finding carries two grades in the style of the Admiralty system: a letter from A to F for the reliability of the source, and a number from 1 to 6 for the credibility of the specific claim. Keeping the two grades separate stops a reliable register from lending weight to a self-declared detail recorded on it.

What is the difference between likelihood and confidence in an intelligence report?

Likelihood says how probable a judgment is, using terms from the UK probability yardstick such as likely or realistic possibility. Confidence, rated High, Moderate or Low, says how solid the foundations of that judgment are, based on source quality, method and how fast the facts are changing. Likely with low confidence is an honest, valid combination.

How do you preserve evidence for an OSINT report?

To preserve evidence for an OSINT report, save each page as a PDF or PNG, record its SHA-256 hash so any later change to the file is detectable, and name files with the source reference and a UTC timestamp. An archive copy made through the Internet Archive's Save Page Now form helps a sceptical reader trust the capture.

How does UserSearch support OSINT reporting?

UserSearch stores search history and bookmarks in a Case when Forensic Mode is on, which gives an OSINT report its method section and negative checks. OneScan merges results with source attribution, and the free Forensic Capture extension records SHA-256 fingerprints and two independent timestamps. SargeBot can draft a PDF report, which the analyst must then verify.

Reports Your Colleagues Can Rerun

A checkable OSINT report is simple to describe and hard to fake: a clear question, a recorded route, graded findings, honest confidence and preserved evidence. The template above gives you the skeleton. The discipline is using it every time, including for the quick jobs, because the quick jobs are the ones that end up being questioned.

Stop guessing. Start researching with UserSearch. One account gives your team 100+ data sources, OneScan to run one input across the sources you choose with attribution on every result, Cases that keep your search history and bookmarks as a ready-made source log, shared Cases for peer review, Forensic Capture for hashed and timestamped evidence, and SargeBot to draft the PDF report you then verify and sign.

About the author

UserSearch Team
Updated on Sep 28, 2026