Open-source intelligence (OSINT) is a discipline of restraint as much as discovery. Anyone can scrape a profile or run a username search, but professional investigators are judged on whether their work is scoped, lawful, repeatable, and safe — for them, for their subjects, and for the integrity of the case. This guide walks through a practical OSINT workflow paired with the operational security (OPSEC) habits that protect both the analyst and the investigation. Treat it as a baseline checklist you can adapt to journalism, threat intelligence, due diligence, or law-enforcement support work.
1. OSINT workflow: structure beats speed
Most failed OSINT engagements fail at the planning stage, not at the keyboard. Before you open a single browser tab, lock in the question you are trying to answer.
Define a precise question
Apply the classic W5H frame — who, what, when, where, why, how — to formulate a tight intelligence requirement. Without a question, OSINT degrades into hoarding: thousands of screenshots, no answer. A specific question scopes your investigation and makes it possible to know when you are finished.
Build a collection plan first
List the data sources, pivots, and selectors you intend to use before you start collecting. This single habit defends against tunnel vision and surfaces gaps early — it is the biggest separator between hobbyist and professional practice. The U.S. Intelligence Community frames collection management the same way for the same reason.
Hash and timestamp every artefact
Every screenshot, document, and downloaded page should be hashed (SHA-256), timestamped, and logged in a chain-of-custody file. Use ExifTool to capture metadata and sha256sum for integrity. The evidentiary value of OSINT is almost entirely a function of provenance — without it, your finding is an opinion, not a finding.
Triple-source every claim
A single source is rumour. Triangulate from at least three independent sources before publishing or escalating. The Global Investigative Journalism Network's verification guides walk through this discipline in depth.
Document your negatives
Record what you searched and did not find. Negative results help reviewers and stop your future self (or a colleague) from re-walking dead ends. They also defend against the cognitive bias of remembering only the searches that produced hits.
2. Tooling baseline: contained, repeatable, graphable
You do not need every tool on the market. You need a small, contained, repeatable stack you trust.
- Investigation OS — run collection from a hardened Linux VM such as Ubuntu, Kali Linux, Parrot OS, or the SANS SIFT Workstation. Keep your Windows or macOS host clean. Containment plus snapshots equal repeatability.
- Case management — pair a capture tool such as Hunchly with a knowledge base in Obsidian or Notion. You want reproducible captures and a place that turns notes into findings.
- Pivoting and graphing — entity graphs from Maltego CE, SpiderFoot HX, or the Recon-ng Framework let you visualise the relationships your collection plan was looking for, and they expose the pivots you would otherwise miss.
3. OPSEC: identity, technical, and data hygiene
OPSEC is the discipline of not leaking information about yourself while you collect it about a subject. Subjects pivot back. Lawyers subpoena. Mistakes compound. Treat the three layers below as non-negotiable.
Identity OPSEC: sock-puppet personas
Use research personas that are completely walled off from your real handles, devices, and payment methods. Each persona deserves its own browser profile, dedicated email, voice number, and — when justified — a residential proxy to defeat fingerprinting. Rotate personas every 6–12 months to avoid long-term reputational baggage and exposure. Bellingcat's getting-started guide covers persona hygiene in practical detail.
Technical OPSEC
- Always use a privacy-respecting DNS resolver and a VPN or Tor as appropriate (and lawful in your jurisdiction). This hides your real IP from logged queries against subject infrastructure.
- Never log in to a target account using your real cookies — cookie and browser fingerprints are persistent leaks across sessions.
- Disable read receipts, last seen, and online status on your messengers. These are the easiest accidental signals to your subject.
Data OPSEC
Encrypt working drives at rest, auto-purge browser caches, and apply data minimisation — retain only the personal data you need to answer the question. This is both a security control and, under the EU GDPR and similar laws, a legal obligation.
4. Legal boundaries you cannot negotiate away
OSINT is "open" — but the law is local. Scraping rules, breach-data handling, and even what counts as a "public record" vary widely between the EU's GDPR, the U.S. Computer Fraud and Abuse Act, the UK Data Protection Act, and Brazil's LGPD. Know which one you are operating under for each subject and each data source.
Two bright lines apply almost everywhere:
- Never log in to an account using leaked credentials. Possessing breach data may be tolerated for research; authenticating with it is unauthorised access under federal computer-crime statutes in most jurisdictions.
- For ICS, IoT, and exposed infrastructure, only banner. Never touch the device. Read what Shodan or similar services already collected; do not interact.
5. Ethics: the trust you cannot rebuild
OSINT can ruin lives. Apply the minimum necessary harm principle: redact uninvolved parties, consult counsel for vulnerable subjects (minors, abuse survivors, asylum seekers, defectors), and refuse work that would have a chilling effect on legally protected speech. Trust is the asset that distinguishes serious practitioners — once it is gone, neither tooling nor reputation will replace it.
One absolute rule: if you encounter child sexual abuse material (CSAM), stop, do not download, and report immediately to the appropriate authority — the NCMEC CyberTipline in the U.S., the Internet Watch Foundation in the UK, or your national equivalent — and to law enforcement. This is both an ethical and a legal duty.
6. Reporting: top-down, evidenced, and access-controlled
Stakeholders read top-down. Lead with a one-paragraph summary, attach an evidence appendix, mark uncertainties explicitly, and describe your methods so the work is auditable. Use the FIRST Traffic Light Protocol (TLP) — currently version 2.0 — to label and control distribution; it is the standard control across CTI and intelligence-sharing communities. Maintain an audit log of who accessed the case file. Insider threat is a real OSINT failure mode, not a theoretical one.
7. Reproducibility: build the case so anyone can retrace it
- Record exact queries — full URLs, parameters, timestamps. Future-you needs to retrace, and a peer reviewer needs to verify.
- Snapshot evidence in two places — push pages to archive.today and the Wayback Machine, and keep offline copies. Sites disappear; takedowns happen.
- Version your dataset — tag releases. If you republish, others must be able to replicate your finding from the same inputs.
Bottom line
A good OSINT workflow is not a list of tools — it is a habit of thinking. Scope the question, plan the collection, hash the evidence, triangulate the claim, document the negatives. Layer OPSEC across identity, technical, and data hygiene. Stay inside the law and inside your ethics. Report top-down with TLP labels, and make the whole engagement reproducible. Tooling like ExifTool, Recon-ng, Maltego, SpiderFoot, and Hunchly simply makes the discipline faster — it does not replace it.