# OSINT Academy — Full Reference

> Open-Source Intelligence — From Curiosity to Capability. This file bundles the core educational content of OSINT Academy (https://os-intelligent.com) as a single plain-text reference for LLM ingestion.

OSINT Academy is a civilian educational resource teaching the full open-source investigation lifecycle — planning, collection, analysis, and reporting — with an explicit focus on legal and ethical boundaries. It is published by Angel Reyes as part of the Subthesis ecosystem. OSINT Academy is not a government agency, is not affiliated with law enforcement or intelligence services, does not host or sell investigative tools, and does not issue certifications.

Canonical site: https://os-intelligent.com
Author: Angel Reyes (Subthesis, https://subthesis.com)
Short index: https://os-intelligent.com/llms.txt

## Methodology overview

OSINT Academy organises open-source investigation into four sequential phases. Each phase has defined inputs, defined outputs, and defined exit criteria. The four phases are:

1. Planning — define the intelligence requirement, the audience, and the legal and ethical guardrails.
2. Collection — gather evidence from public sources with documented provenance, hashes, and archival captures.
3. Analysis — corroborate, apply structured analytic techniques, and calibrate confidence.
4. Reporting — translate verified findings into outputs the consumer can act on.

The full per-phase treatment follows.

## Methodology: Planning

Source: https://os-intelligent.com/methodology/planning/


Planning is the phase most beginners skip and most experienced investigators spend a third of their time on. The reason is simple: everything downstream either pays the debt of good planning or pays the interest on bad planning. An investigation without a clear question collects the wrong evidence. An investigation without a defined audience produces a report that nobody can act on. An investigation without ethical guardrails discovers them the hard way, in a takedown notice or a subpoena.

## What planning actually produces

At the end of this phase you should be able to answer five questions in one sentence each:

1. **What is the intelligence requirement?** The specific question you are trying to answer, written so narrowly that somebody else could tell when you have answered it.
2. **Who is the consumer?** A judge, an editor, a compliance committee, a funder, a jury, the public — each has a different standard of proof and a different tolerance for hedging.
3. **What counts as proof?** Two independent sources? A single primary document? A pattern across a dataset? Decide now, not after you find something interesting.
4. **What are the legal constraints?** Jurisdiction of the subject, jurisdiction of the investigator, any platform terms of service that apply to your method of access.
5. **What is out of scope?** The questions you will deliberately not pursue — usually because they are legally risky, ethically disproportionate, or not your job.

If you cannot answer those five questions, you are not ready to collect. You are ready to plan.

## Framing the intelligence requirement

Vague requirements generate vague investigations. "Find out who owns this company" is not a requirement; it is a wish. A real requirement looks like: "Identify the ultimate beneficial owners of Acme Holdings BV and any natural persons holding more than twenty-five percent of the equity, as recorded in public corporate registries as of a specified date, to support a KYC file."

The rewrite forces four decisions: the legal standard (UBO at twenty-five percent), the source class (public registries), the temporal bound (as of today), and the downstream use (KYC file). Each of those decisions shapes the collection plan.

## Identifying sources before collecting

Before you open a browser, list the source classes that could plausibly answer your question. Not specific URLs — classes. For a corporate ownership question that might be: domestic company registry, beneficial ownership registry where one exists, court filings, regulatory disclosures, press coverage, social media of named officers, archived web content for old incarnations of the company's own site. Rank them by evidentiary weight: primary government records at the top, secondary reporting in the middle, social media at the bottom.

Rank them again by access friction. A registry that requires a paid subscription still counts; a leaked database of unknown provenance does not. The cheap-and-authoritative intersection is where you start.

## Setting the standard of proof

A common beginner failure is treating all evidence as equal. It is not. A screenshot of a tweet is weaker than an archived copy of the tweet, which is weaker than the platform's own record retrieved via API, which may be weaker still than a court-authenticated export. Decide, at planning time, how much weight each tier carries for this specific question, and commit that to the investigation brief.

The same question also forces you to think about falsification. What would make you conclude the opposite of your hypothesis? If nothing could, you are not investigating — you are confirming.

## Legal and ethical guardrails

The planning phase is where you document what you will not do. Common guardrails:

- No pretexting, no creation of false identities to access information, no social engineering of private accounts.
- No access to systems that require credentials you were not given, including accounts you find leaked in breach data.
- No targeting of minors, victims of crime, or protected classes beyond what the question strictly requires.
- Explicit consideration of the proportionality between harm risk and public interest.

Write these down. They are the first thing a defence lawyer, an ethics board, or a senior editor will ask about if the investigation is ever challenged.

## Common pitfalls

**Tool-led planning.** Starting from "I know how to use Shodan, what can I do with it?" instead of "I have a question, is Shodan relevant?" This is how investigators waste a week and produce noise.

**Question drift.** The initial requirement was narrow; three pivots later the investigator is researching something nobody asked about. Pivots are fine — they are how investigations work — but they must be documented and re-scoped, not silently absorbed.

**Confirmation framing.** Writing the requirement in a way that presupposes the answer. "Find evidence that X owns Y" is not an intelligence requirement; it is a brief for a fabrication. "Determine whether X owns Y" is the investigable version.

**Ignoring the adversary model.** If your subject has reason to expect scrutiny, they have probably scrubbed the easy sources already. Plan accordingly — archives, caches, and metadata are more likely to survive than live pages.

## Tools relevant to this phase

Planning is mostly paper work, but a few tools help. Intelligence-requirement templates and source-mapping worksheets live in the [resources library](/resources/). For background on the subject before collection proper, use the [Wayback Machine tutorial](/tools/wayback-machine/) to scope the historical footprint and [WHOIS and DNS lookup](/tools/whois/) to identify related infrastructure. These are reconnaissance, not collection — use them to shape the plan, then re-collect under the plan.

## Deliverables checklist

By the end of planning you should have:

- A one-paragraph intelligence requirement.
- A named consumer and a defined standard of proof.
- A ranked list of source classes with expected evidentiary weight.
- A scoped-out list of questions you will not pursue.
- A written set of legal and ethical guardrails for this specific investigation.
- A target completion date, or the trigger condition that ends the investigation.

Carry this document into the next phase. If collection starts pulling against it, come back here — do not let the evidence quietly redefine the question.

Next phase: [Collection](/methodology/collection/).


## Methodology: Collection

Source: https://os-intelligent.com/methodology/collection/


Collection is where the investigation meets the real world, and where most of the errors that will later blow up the analysis are quietly introduced. The phase is deceptively simple — go find the information — but the discipline is not in what you find; it is in how you record finding it. A claim with a screenshot is gossip. A claim with a timestamped, hashed, archived, and logged capture is evidence.

## The goal of collection

The collection phase produces two artefacts: the data itself, and the record of how the data was acquired. The second artefact is usually more important than practitioners realise. If your investigation is ever contested — by a source, a lawyer, a regulator, an editor, or a referee — you will be asked not what you found but how you found it, when you found it, and whether you can prove the thing you found was there at the time you say it was.

Assume from the first click that you will need to reconstruct your collection path six months later for somebody hostile. Design the workflow for that reconstruction.

## What good collection looks like

For every piece of evidence captured, record:

- **Source URL**, including query parameters, in full.
- **Timestamp of capture**, in UTC, to at least minute precision.
- **Capture method** — browser screenshot, wget, API call, archive submission.
- **Hash** of the captured artefact (SHA-256 is standard).
- **Archival copy** submitted to a third-party archive (Wayback Machine, archive.today) before any further action on the page.
- **Investigator notes** — what the capture is intended to prove, and anything about the access conditions (logged in, specific region, specific device) that could affect reproducibility.

A spreadsheet, a markdown log, or a dedicated tool like Hunchly all work. What matters is that the schema is consistent and the log is written at the time of collection, not reconstructed from memory afterwards.

## Source classes and their handling

**Primary government records** — registries, filings, court dockets, regulatory submissions. Treat as high evidentiary weight. Capture the page, capture the underlying document if linked, and record the registry's own version or revision identifier where available. Do not paraphrase; quote.

**Secondary reporting** — news articles, trade press, academic papers. Treat as leads, not findings. Reporting is useful to point you at primary sources but is itself a chain-of-citation problem. Trace each claim to its origin before relying on it.

**Social media** — posts, profiles, public interactions. Treat as volatile. Archive immediately, because the content can be edited or deleted between the moment you find it and the moment you cite it. Preserve the full thread context, not just the target post.

**Technical artefacts** — DNS records, IP addresses, domain registration data, certificate transparency logs, server banners. Treat as corroborative. A registrant record matches or does not match a claim elsewhere; on its own it rarely proves anything.

**Leaked or breached data** — treat as radioactive until you have a legal and ethical opinion on handling. Many jurisdictions distinguish between publicly indexed leaks and directly obtained breach data, and some impose obligations on possession regardless of source. Do not assume permission from availability.

## Preserving provenance

The single most common failure in OSINT is losing the chain from a published finding back to the moment of its collection. The fix is boring and reliable: archive before you act. Before you tweet about a finding, before you pivot on it, before you even tell a colleague — submit the source URL to the Wayback Machine and archive.today, save a local PDF or WARC, and hash both. The cost is thirty seconds per artefact. The cost of not doing it is an investigation that collapses when the page changes.

A common trap: using a satellite image or a public photo to confirm a location before cross-checking the caption against a reverse image search. The image may be real, the caption may be a relabel, and the mistake will survive publication if no independent provenance was captured.

## Tools relevant to this phase

- [Wayback Machine](/tools/wayback-machine/) for both submitting and retrieving archival captures.
- [WHOIS and DNS lookup](/tools/whois/) for domain and infrastructure provenance.
- [Google dorking](/tools/google-dorking/) for targeted discovery of documents indexed but not linked from obvious places.
- [Shodan](/tools/shodan/) for internet-exposed infrastructure associated with a target.
- The [Subthesis legal document analysis tool](https://subthesis.com) for systematic extraction of entities and claims from long documents captured during collection.

Match the tool to the source class. Shodan is wasted effort on a question about corporate ownership; a company registry search is wasted effort on a question about exposed services.

## Common pitfalls

**Collecting before planning is complete.** The seductive mistake. You find a thread, you pull it, and an hour later you have a hundred tabs open and no idea which ones you can cite.

**Contaminating the subject.** Logged-in searches, account visits, and direct messages may be visible to the subject. For sensitive work, use a clean browser profile, consider a VPN, and avoid any action that creates a notification or an access-log entry against the target.

**Over-collecting.** Evidence you did not scope is evidence you may legally need to disclose or ethically need to consider. Collect what answers the question; resist the urge to hoover.

**Relying on live links in the final report.** The page you cited will move or disappear. Every citation should point to an archive, with the original URL noted for transparency.

## Deliverables checklist

By the end of collection you should have:

- A complete capture log with timestamps, hashes, and archive URLs for every artefact.
- Archived copies of every live source submitted to at least one independent archive.
- Organised evidence folders keyed to the intelligence requirement from planning.
- A running list of gaps — claims you cannot yet substantiate — to carry into analysis.
- A written note of any access conditions, VPN use, or accounts that might affect reproducibility.

Collection ends not when you run out of sources but when the evidence against the plan is sufficient to make a defensible finding — or to conclude the question cannot be answered from open sources. Either outcome is legitimate.

Previous phase: [Planning](/methodology/planning/). Next phase: [Analysis](/methodology/analysis/).


## Methodology: Analysis

Source: https://os-intelligent.com/methodology/analysis/


Analysis is the phase that separates an investigator from a collector. Anyone with patience can pile up documents. Analysis is what turns the pile into a finding — or, more often and more usefully, into a specific admission of what the evidence cannot yet support.

The phase has three jobs: corroborate each claim across independent sources, structure the relationships between entities and events so they can be reasoned about, and deliberately attack your own hypothesis with the evidence that would falsify it.

## Corroboration, not accumulation

One source is a lead. Two independent sources pointing at the same fact is a finding. Three is a finding you can cite with confidence. The word doing the work here is **independent**. Two news articles citing the same press release are one source. Two tweets quoting the same original tweet are one source. Independence is not multiplicity; it is the absence of a common upstream.

In practice, trace every claim you intend to publish back to its primary source. If you cannot reach a primary source, mark the claim as derivative in your notes and downgrade its evidentiary weight. If two paths to the same claim turn out to collapse into one, downgrade accordingly. Most of the errors in circulated OSINT analysis come from treating dependent corroboration as independent.

## Triangulation across source classes

Stronger still than two independent sources of the same class is triangulation across classes. A corporate filing, a press mention, and a domain registration that all place the same person at the same company at the same time tell a coherent story in a way that three press mentions do not. Where possible, build each finding from at least two different classes of evidence: primary government record, secondary reporting, technical artefact, first-party statement.

## Structuring the evidence

Unstructured notes do not scale past a handful of entities. Invest in a minimal structure early:

- An **entity list** — every person, organisation, address, domain, account, vessel, or account number you have seen. Each entity gets an identifier that is stable across your notes.
- A **relationship log** — directed links between entities, each one backed by one or more evidence identifiers from the collection log.
- A **timeline** — dated events, with source references, allowing you to spot sequence and gaps.

For link-heavy investigations, a dedicated tool like Maltego or a graph database is worth the setup cost. For most investigations, a three-tab spreadsheet is plenty. The discipline matters more than the tooling; fancy software applied to sloppy structure produces confident-looking nonsense.

## Testing alternatives

The analytic step most beginners omit is the adversarial one. For every finding, ask: what alternative explanation could produce the same evidence, and what evidence would rule that alternative out?

A common trap: concluding that two social media accounts belong to the same person because they post similar content from the same city. Alternative explanations include shared interests, a shared workplace, a shared ghostwriter, or a deliberate attempt to create an appearance of connection. Ruling the alternatives out requires evidence that only one of the hypotheses predicts — a shared device fingerprint, overlapping private-but-leaked metadata, an admission.

Write the alternative explanations down. A finding that survives written alternatives is stronger than a finding that has only been mentally considered.

## Timelines, patterns, and the limits of each

Timelines expose sequence. If a company was incorporated after an event it supposedly caused, that is not a subtle analytic point; it is a dispositive one. Build the timeline before the narrative. The narrative should fit the timeline, not the other way round.

Patterns — recurring names, addresses, phone numbers, wallet addresses — are seductive. They are also the most common vector for false positives. A pattern is a hypothesis, not a conclusion. Treat pattern matches as leads that require their own corroboration.

## Metadata and technical analysis

Documents, images, and archives often carry metadata that survives casual handling. EXIF data in photos, author fields and edit histories in office documents, headers in emails, certificate chains on websites — each can corroborate or disprove a claim about origin. Extract metadata systematically; log what was present and what was absent; remember that the absence of metadata on a file that should have it is itself informative.

Be cautious with metadata as a primary source. It is trivial to alter, and sophisticated subjects will have. Use it as one strand among several, and never as a lone pillar of a published finding.

## Common pitfalls

**Narrative capture.** You form a theory early, and from that point forward every new piece of evidence is read as confirmation. Mitigate by writing the adversarial alternatives before you review new evidence, not after.

**Circular corroboration.** Two sources pointing at the same fact because one sourced it from the other. The fix is to trace every citation to its origin.

**Over-precision.** Claiming a finding is established when the evidence supports only that it is plausible. The reporting phase rewards hedging honestly; analysis is where you decide how much to hedge.

**Ignoring null findings.** The absence of an expected record is often the most informative signal in the investigation. A company that claims twenty years of operation but appears in no registry until last month is telling you something specific.

## Tools relevant to this phase

- [Maltego](/tools/maltego/) for link analysis when the relationship graph grows past what a spreadsheet can hold.
- [Metadata extraction](/tools/metadata-extraction/) for images and documents captured during collection.
- [Reverse image search](/tools/reverse-image-search/) for provenance of visual evidence.
- The [Subthesis legal document analysis tool](https://subthesis.com) for structured extraction of entities, claims, and citations across long documents.
- Timeline and entity-mapping templates from the [resources library](/resources/).

## Deliverables checklist

By the end of analysis you should have:

- A consolidated entity list with stable identifiers.
- A relationship log, each edge backed by evidence references.
- A timeline covering the events relevant to the intelligence requirement.
- A written set of findings, each graded by evidentiary weight and each accompanied by the alternatives considered and ruled out.
- An explicit list of claims you cannot support — the gaps that the reporting phase must disclose rather than hide.

The output of analysis is not "the answer." It is the evidentiary case for each finding and the honest boundary of what the open sources will bear.

Previous phase: [Collection](/methodology/collection/). Next phase: [Reporting](/methodology/reporting/).


## Methodology: Reporting

Source: https://os-intelligent.com/methodology/reporting/


Reporting is where the investigation becomes useful to somebody other than the investigator. It is also where the discipline of the previous three phases pays out, or where it is squandered. A report that overstates its findings burns the investigator's credibility. A report that buries a clear finding in hedges fails its audience. The task is to communicate exactly what the evidence supports — no more, no less — and to preserve the path back to source so that a reader can verify every claim without the investigator's help.

## Know your reader

The single most important question before drafting is: who is this for, and what decision will they make with it? The same evidence becomes a different report depending on whether the consumer is a judge weighing admissibility, an editor deciding whether to publish, a compliance committee onboarding a counterparty, or a public audience assessing accountability.

A legal memo requires explicit citation to authority, a clean chain of custody, and hedged language that accurately reflects evidentiary limits. A news article requires a lead that conveys the finding and a narrative that guides a general reader through the evidence. A compliance report requires structured fields, defined risk ratings, and a record of the sources checked. Do not write a single report in the hope it will serve every audience; pick one and write it properly.

## The structure of a defensible report

Regardless of audience, a defensible OSINT report contains the same sections in some order:

- **Intelligence requirement** as stated at the planning phase, with any documented scope changes.
- **Summary of findings**, each one graded by evidentiary weight and hedged to match.
- **Evidence** for each finding, cited to a specific artefact in the collection log — not to a live URL.
- **Alternative explanations considered**, and what evidence (if any) would change the conclusion.
- **Gaps and limitations** — the claims the evidence does not support, and why the investigation did not close them.
- **Methodology note** — what sources were queried, what was out of scope, and what tooling was used.
- **Annex** of exhibits, or an index into the collection log.

A reader who reaches the end of the report should be able to answer: what did the investigator find, how strong is the basis for each finding, and what alternative explanations remain on the table.

## Evidentiary language

The vocabulary of honest reporting is narrow. Use it consistently:

- **"The records show..."** when citing a primary document.
- **"According to [source]..."** when citing secondary reporting.
- **"Open sources indicate..."** when drawing an inference from multiple corroborating sources.
- **"The evidence is consistent with..."** when a finding is supported but not dispositive.
- **"The evidence does not establish..."** for claims that could not be substantiated.

Avoid language that asserts certainty the evidence does not support. "X is the owner" is an assertion; "Registry records filed on [date] list X as the ultimate beneficial owner" is a citation. The second survives scrutiny; the first invites it.

## Preserving the chain

Every cited claim in the report should resolve, through a footnote or an endnote, to an artefact in the collection log. The artefact in turn resolves to an archival URL, a hash, a timestamp, and the investigator's capture notes. A reader — or a hostile reviewer — should be able to travel from a sentence in the report to the exact captured page that supports it in under a minute.

This is the single most important quality differentiator in OSINT reporting. Work that preserves the chain back to source is checkable, defensible, and re-usable. Work that does not is trivia.

## Responsible disclosure and harm

Before publication, weigh the harm of publishing against the public interest. Some findings name natural persons whose involvement is incidental; some expose security weaknesses that can be exploited; some touch on victims who have not consented to further visibility. Standard practice:

- Redact or anonymise data on minors, victims, and bystanders whose presence is incidental to the finding.
- Hold technical findings (exposed credentials, vulnerable systems) for responsible disclosure to the affected party before publication.
- Offer subjects of significant findings a right of reply in advance of publication, where safe and feasible.
- Distinguish between private facts and public conduct; the latter is generally fair game, the former generally is not.

The [ethics and legal framework](/ethics/) goes into each of these in more depth. Reporting is the phase where those principles become decisions with names attached.

## Tools relevant to this phase

- The [Subthesis legal document analysis tool](https://subthesis.com) for consolidating long evidence trails into structured summaries.
- Report templates and citation formats from the [resources library](/resources/).
- Hashing utilities for exhibit integrity; keep the hashes produced at the collection phase and reference them in the annex.

## Common pitfalls

**Burying the lede.** The reader does not want a narrative of your investigation; they want the finding. Open with the finding, then justify it.

**Over-claiming.** The evidence supports a specific conclusion; the draft says something broader. Edit down, not up.

**Under-claiming.** The evidence clearly supports a finding, but the draft hedges past the point of usefulness. Clarity is not the enemy of rigour; vagueness is.

**Losing the chain.** Citing a live URL that will die, instead of the archive captured during collection. The citation should point at an artefact whose integrity you control.

**Publishing without internal review.** A second reader, ideally adversarial, catches errors that the investigator is blind to by this point in the work.

## Deliverables checklist

By the end of reporting you should have:

- A report tailored to a named audience, with language matched to their standard of proof.
- A findings section where every claim is graded and hedged honestly.
- A citation apparatus that resolves every claim to a preserved artefact.
- An explicit limitations section.
- A preserved exhibit archive, hashed and stored independently of the live web.
- A record of responsible-disclosure decisions, including any redactions applied and why.

When the report is delivered, the investigation is not quite finished. Preserve the full artefact set for the retention period appropriate to the domain — typically several years — so that challenges or follow-ups can be addressed from the evidence, not from memory.

Previous phase: [Analysis](/methodology/analysis/). Return to the [methodology overview](/methodology/).


## Ethics and Legal

Source: https://os-intelligent.com/ethics/


OSINT is defined by the public availability of its sources, but availability is not permission. The methods described across this site can be applied well or badly; can produce accountability or harassment; can illuminate or defame. The difference is rarely in the tooling. It is almost always in the discipline the investigator brings to the work.

This page sets out the framework we expect readers to apply. It is not legal advice; read the disclaimers at the end before relying on anything here.

## Why ethics matter in OSINT

Open-source investigation concentrates power asymmetrically. The subject of an OSINT investigation does not consent to it, is often unaware of it, and usually has no recourse against it during collection. The investigator decides — unilaterally — what questions to pursue, which individuals to put under scrutiny, and what to publish. That asymmetry is not unique to OSINT; police, journalists, and auditors all operate inside it to varying degrees. What is distinctive is that OSINT tooling has collapsed the barrier to entry. A practice that used to require institutional backing can now be initiated by anyone with a laptop.

This site takes the position that the collapse of the barrier makes ethics more, not less, important. Without institutional constraints — editors, compliance teams, ethics boards, supervising counsel — the discipline must come from the practitioner. Otherwise, OSINT is indistinguishable from harassment dressed in better software.

The core ethical premises of OSINT we teach:

- **Proportionality.** The intrusion of the investigation on the subject's interests should be proportionate to the public value of the question. Minor curiosity does not justify major scrutiny of private persons.
- **Minimisation.** Collect what answers the question, not what is available. Evidence about bystanders, family members, and incidental figures should be excluded or redacted unless their inclusion is necessary.
- **Verifiability.** Every claim made in public should be supportable from preserved sources that a reader can re-examine. Investigations that cannot be audited are not findings; they are rumours.
- **Honesty about uncertainty.** The evidence bears a specific finding; the investigator states that finding and not a broader one. Over-claiming harms subjects unjustly and damages the practice over time.
- **Concern for harm.** Publication of a finding is a separate decision from the validity of a finding. A correct finding can cause disproportionate harm; responsible investigators weigh the harm and decide accordingly.

## Legal frameworks by jurisdiction

OSINT touches several bodies of law that vary sharply across borders. What follows is an orientation, not a summary; specific applications require local counsel.

### United States

- **Computer Fraud and Abuse Act (CFAA).** The CFAA prohibits access to computer systems "without authorisation" or "exceeding authorised access." Recent Supreme Court guidance has narrowed some interpretations, but the statute remains the primary risk for techniques that border on unauthorised access — including automated scraping of sites that prohibit it.
- **State privacy and defamation.** Defamation, intrusion upon seclusion, and publication of private facts are state-law torts with materially different standards across jurisdictions. Truth is a defence to defamation; it is not always a defence to the other two.
- **Constitutional protections.** First Amendment protection for newsgathering and publication is substantial but not unlimited. Constitutional rights during investigative encounters — including immigration enforcement contexts — are covered in practical form at [ICE Encounter rights guides](https://iceencounter.com).
- **FERPA, HIPAA, GLBA.** Education, health, and financial data carry statutory handling obligations. Public availability of a leaked document does not override those obligations once the data is in your possession.

### European Union and EEA

- **General Data Protection Regulation (GDPR).** Processing of personal data requires a lawful basis regardless of source. OSINT practitioners in or targeting the EU must identify a basis — legitimate interest, legal obligation, public interest — and document it. "It was on the internet" is not a basis.
- **Member-state criminal law.** Unauthorised access, data-protection breaches, and defamation regimes differ by member state. Investigations across borders require legal review of each touch point.
- **Journalistic exemptions.** Most member states implement a journalistic-purpose exemption that narrows GDPR application for recognised journalism; its scope varies and should not be assumed.

### United Kingdom

- **UK GDPR and Data Protection Act 2018.** Broadly parallel to the EU regime post-Brexit, with its own enforcement regulator (ICO) and its own guidance.
- **Computer Misuse Act 1990.** Similar in spirit to the CFAA — unauthorised access is an offence. Scraping that violates a site's terms may implicate the statute.
- **Defamation Act 2013.** Requires "serious harm" for defamation actions; has specific provisions for publications online.
- **Investigatory Powers Act.** Primarily targets state actors, but its standards inform the social expectation around investigative conduct.

{% set variant = "legal" %}
{% set warningTitle = "Jurisdiction of the subject, not just the investigator" %}
{% set warningBody = "Several of the regimes above apply based on the location of the data subject, not the location of the investigator. A UK-based investigator researching a German resident is typically within the UK GDPR and the EU GDPR simultaneously. Design the collection method to satisfy the strictest applicable regime." %}
{% include "partials/warning-box.njk" %}

## The ethical investigator's checklist

Before beginning an investigation, answer each of the following in writing. If any answer is unsatisfactory, the investigation is not ready to start.

1. **What is the public-interest justification?** Stated plainly enough that a reasonable third party would accept it.
2. **Is the intrusion proportionate?** Does the question require the depth of scrutiny you are planning?
3. **What legal regimes apply?** List the jurisdictions of the investigator, the subject, any data processors, and the likely publication venue.
4. **What guardrails are in place?** No pretexting, no unauthorised access, no targeting of minors or victims beyond what the question strictly requires.
5. **What is the responsible-disclosure path?** If the investigation uncovers vulnerabilities, harms in progress, or threats to third parties, to whom and how will those be reported?
6. **Who else reviews the work before publication?** A second reader — editor, supervisor, counsel, trusted peer — is not optional for work intended for public release.
7. **What is the retention plan?** How long will the evidence be held, and under what conditions will it be destroyed?

Carry this checklist into every investigation. Archive it with the evidence.

## Common legal pitfalls

**Scraping in violation of terms.** Automated collection against a site's prohibition can implicate computer-misuse statutes even where the data is technically public. Use published APIs where available; respect robots.txt and rate limits for the rest.

**Aggregation harm.** Many individual facts that are separately public become privacy-invasive in combination. Aggregation of public records into a dossier on a private individual may be lawful in the abstract and tortious in the particular. Test proportionality.

**Defamation by implication.** Publishing true facts that together imply a false defamatory claim exposes the investigator in most jurisdictions. Words not written can still be actionable if the juxtaposition makes the implication unmistakable.

**Handling breach data.** Possession and processing of data known to have been obtained through a breach can carry independent liability, varying by jurisdiction, regardless of public circulation. Get a written legal position before ingesting such a source into a live investigation.

**Tipping off.** In regulated AML and compliance workflows, notifying a subject of an investigation can be a criminal offence. Passive OSINT is generally safe; account creation, follow requests, and direct-message attempts are not.

{% set variant = "critical" %}
{% set warningTitle = "When in doubt, do not" %}
{% set warningBody = "If a proposed technique sits close enough to a legal or ethical line that you are asking the question, the answer is usually to stop, document, and escalate. Investigations that get into serious trouble usually did so after the investigator overrode a small hesitation. Trust the hesitation." %}
{% include "partials/warning-box.njk" %}

## Ethical frameworks applied to OSINT

Three normative frameworks are routinely invoked in investigative ethics. Each gives different guidance on the same case; investigators who know only one miss the force of the others.

**Utilitarian.** Judge the act by its consequences: does the investigation produce more good than harm, summed across everyone affected? Useful for publication decisions where the harm and the benefit are both concrete. Weak when the benefits are speculative and the harms are certain, which is a surprisingly common case.

**Deontological.** Judge the act by whether it respects duties and rights — to privacy, to truthfulness, to treating subjects as ends rather than means. Useful as a check on utilitarian reasoning that slides toward "the end justifies the means." Weak when duties conflict, which they often do in investigations.

**Virtue ethics.** Judge the act by whether a person of good character, doing the job well, would do it. Useful for decisions that neither consequences nor duties decide cleanly. Operationally: ask what a senior investigator you respect would do, and be prepared to explain any deviation.

In practice, an experienced investigator cycles through all three. A proposed technique survives if it produces a clear net benefit, respects the rights of the subject and bystanders, and is the kind of thing a skilled practitioner would be comfortable owning.

## Privacy considerations

OSINT and privacy are often framed as opposites; they are not. Privacy-respecting investigation is possible and is generally the higher-quality practice. Some operating principles:

- **The public-private boundary is contextual, not binary.** A fact posted on a public profile in 2012 may have been effectively private in that context. Lifting it into a 2026 investigation changes the context materially. Treat the context shift as a privacy question, not a technicality.
- **Minors are categorically different.** Most ethical frameworks and many legal regimes apply stricter protections to data about minors. Default to exclusion; make any inclusion an active, documented decision.
- **Victims are not sources.** Open evidence about victims of crime or violence can be reidentifying. Redact unless their identification is itself the finding.
- **Bystander data survives the investigation.** Family members, colleagues, and coincidental appearances in the evidence base should not be further investigated unless the question requires it.

## Responsible disclosure

Open-source investigation often uncovers issues that deserve disclosure beyond the investigator's immediate audience: exposed credentials, vulnerable systems, ongoing harms, threats to specific individuals. Responsible practice:

- **Technical vulnerabilities** should be reported to the affected party with a reasonable remediation window before any public discussion, following the organisation's published disclosure policy where one exists.
- **Threats to individuals** — stalking patterns, planned violence, trafficking indicators — should be reported to the appropriate authority or to a specialised responder (NCMEC, domestic-violence organisations, platform trust-and-safety teams) rather than published.
- **Findings affecting named subjects** in reports or articles should be shared with those subjects in advance of publication, with specific questions and a real response window, except where doing so creates a safety risk to sources.

Disclosure is a discipline. It is not served by either silent sitting on information or reflexive publishing.

## Required disclaimers

- All techniques described on this site are intended for lawful purposes only. Users are responsible for compliance with applicable laws in their jurisdiction.
- This site does not encourage or endorse unauthorized access to computer systems, private data, or protected information.
- OSINT techniques should be used within legal boundaries. Consult a legal professional if you are unsure about the legality of a specific technique in your jurisdiction.
- Not affiliated with any government agency, law enforcement body, or intelligence organization.
- Case studies reference publicly available information and published investigations only.

## Further reading

- [Methodology overview](/methodology/) — the four-phase framework these principles apply to in practice.
- [Legal boundaries of OSINT](/blog/legal-boundaries-of-osint/) — a longer treatment of the jurisdictional considerations.
- [ICE Encounter rights guides](https://iceencounter.com) — constitutional rights context for investigations touching immigration enforcement.
- [Epstein Revealed investigation series](https://epsteinrevealed.com) — the ecosystem's long-form application of this framework.
- [Subthesis research tools](https://subthesis.com) — methodology resources extending beyond OSINT.


## Ecosystem

- Subthesis (https://subthesis.com) — research methodology and the Subthesis legal document analysis tool
- Epstein Revealed (https://epsteinrevealed.com) — long-form investigative journalism applying OSINT methodology to public records
- ICE Encounter (https://iceencounter.com) — constitutional rights and documentation guidance during immigration enforcement encounters
- Grant Writing Consultant (https://grantwritingconsultant.com) — funding resources for investigative research and nonprofit accountability work

## License

All content Copyright Angel Reyes / Subthesis. Links and citation welcome. Republishing terms at https://os-intelligent.com/terms/.