Skip to content
New

DeepSeek V4.1 Flash free for 7 days: 10M tokens a day after any top-up. Until Nov 30.

How it works

OSINT Ethics and Privacy: What You Should Not Collect

Learn purpose, proportionality, consent and data minimisation for OSINT, with LGPD and GDPR basics and a one-page research plan template.

Beginner11 min readBy NotHoly

Public information is not the same as information you may collect. A profile can be visible to anyone and still be a poor subject for your research. Ethics in OSINT means deciding, before the first search, why you are looking, who has agreed to it, what you will keep, and when you will delete it. This article shows how to make those decisions and how to write them down in a one-page plan. It assumes you have read What Is OSINT.

What ethics means in OSINT

In this field, ethics is practical. It shapes the choices that define a collection: which question you ask, which sources you open, how much you record, and what you publish. Law sets a floor. Professional practice usually sits above it, because a lawful collection can still hurt people who had no say in it.

Five ideas cover most cases: purpose, proportionality, authorisation, minimisation, and retention. You can apply all five with a pen and a blank page, before you open a browser.

Purpose limitation

Write one sentence that names the decision your research supports. "Find out what I can about this person" is a wish, not a purpose. "Confirm whether every domain registered under our company name is in our asset inventory" is a purpose. A good purpose tells you which sources matter and which results are noise.

Data gathered for one purpose should not drift into another. If a review of your company's domains turns up a personal social media account of an employee, that account stays outside the review, even though you found it.

Proportionality

Ask whether the depth of the collection fits the importance of the question. A routine check of a supplier's public security advisories does not justify a timeline of its staff.

Proportionality covers method too. A passive lookup in public records is a lighter intrusion than sending requests to a live server. The question should decide which kind of step you need, and when the lighter step answers the question, take it.

In security work, the people who can approve your research are the owners of the assets. If you assess an organisation, the written authorisation should name the organisation, the assets, the period, and the methods allowed. A missing authorisation is a reason to stop, not a detail to fill in later.

Public research on an organisation you do not represent still needs a reason that a reasonable person would accept. It must also stop where a named person's private life begins. Consent is a legal basis for personal data in some regimes and one option among several in others. A page being public does not give you a shortcut.

Data minimisation

Collect the fields you need to answer the question, and nothing else. To check whether a domain points to your mail server, you need the domain, the record type, the answer, and the time you observed it. You do not need the registrant's home address, the full HTML of a page with unrelated comments, or a screenshot that shows a stranger in the background.

Minimisation is cheaper than cleanup. Every field you do not collect is a field you cannot leak.

Retention and deletion

Write down how long you will keep the material and who can read it. A reasonable pattern is to keep the evidence that supports each finding, delete raw personal data once the report is accepted, and record the deletion date. The exact number of days depends on your engagement and on the law that applies to you. What matters is that the date exists in the plan, not only in your memory.

Why public data is not automatically fair game

Three reasons explain it.

First, people publish information for a purpose. A wedding photo is shared with friends, a résumé with recruiters, and a forum post with a hobby group. Moving that information into a new context can cause harm even when nothing was hacked.

Second, aggregation creates new information. An address, a workplace, a child's school, and a gym schedule may each be harmless alone and dangerous together. A compiled profile can expose someone in a way no single source did.

Third, public sources include data that was leaked, scraped, or posted by someone else. The person it describes may never have meant it to be shared, and holding it may be unlawful. Access tells you that you can see something. It says nothing about whether you should keep it.

Private individuals are off limits for practice

Do not practise OSINT on private individuals. That includes friends, former partners, colleagues, neighbours, people you met online, and public figures you happen to dislike. Learners often want a real name to test a technique. That is exactly when the technique starts to hurt someone.

Use what you control instead: your own accounts and domains, a test organisation you are authorised to assess, or the synthetic data in your lab. If a classroom exercise needs a target, invent one and build its data yourself. Searching your own name to see your own exposure is a useful exercise, and it still needs a written purpose.

Most readers in Brazil or the European Union will fall under one of two laws. This section is an overview, not legal advice. If your work touches personal data at scale, speak with a lawyer who knows your jurisdiction.

Brazil: LGPD

Lei 13.709/2018, the Lei Geral de Proteção de Dados (LGPD), governs the processing of personal data by individuals and companies, online and offline, with some exceptions. Three parts matter for a researcher.

Article 6 lists the principles. Two carry most of the weight here. Finalidade (purpose) requires legitimate, specific, and explicit purposes that the person can know about. Necessidade (necessity) limits processing to what is relevant and proportionate to those purposes. Adequação (adequacy) asks that processing fit the stated purpose in its context.

Article 7 lists ten legal bases. Consent is one of them, but it is not the only one. Legitimate interests (item IX) are available, but they yield where the person's fundamental rights prevail, and they still have to satisfy the principles in article 6. Studies by research bodies (item IV) are also listed, with a preference for anonymising data where possible.

Article 4, item III, excludes processing done exclusively for public security, national defence, state security, or criminal investigation and repression. Private researchers should not assume that exemption covers them. It is meant for specific legislation and public authorities, and paragraph 2 restricts private entities from processing under it except under public-law oversight. A consultancy working for a client is not a public authority.

Articles 15 and 16 cover when processing ends and when data must be deleted. Article 5, item III, defines anonymised data, and article 12 says that anonymised data is not personal data unless the anonymisation can be reversed with reasonable effort. In practice, a dataset you call anonymous still needs care. A few quasi-identifiers, such as postcode, job title, and date of birth, can single out a person.

European Union: GDPR

Regulation (EU) 2016/679, the General Data Protection Regulation (GDPR), defines personal data broadly in article 4(1) as information relating to an identified or identifiable natural person. Article 5 sets the principles. Point (b) covers purpose limitation, point (c) data minimisation, and point (e) storage limitation. Paragraph 2 makes the controller responsible for showing compliance.

Article 6 lists the lawful bases. Article 9 covers special categories of data, such as health, political opinions, and religious beliefs, which need an additional condition. Article 17 covers erasure. Article 35 requires a data protection impact assessment where processing is likely to be high risk.

The household exemption in article 2(2)(c) covers purely personal or household activity. It does not cover professional research. Once you work for a client, you are outside it.

What the laws mean for your plan

Both laws ask the same questions: why, on what basis, how much, for how long, and who can see it. A research plan that answers those questions in advance will satisfy most of the obligations that apply to a small investigation. The exercise below asks each question directly.

The Berkeley Protocol as a professional reference

The Berkeley Protocol on Digital Open Source Investigations was developed by the Human Rights Center at the University of California, Berkeley, and published by the United Nations Human Rights Office. It is a reference for investigators who work with digital open-source material, including human rights and accountability work. It treats planning and the ethical and legal framework as the starting point of an investigation, not an afterthought.

You do not need to be a human rights investigator to learn from it. Its ethical sections show how careful practitioners think about harm before the first query. Read the protocol itself before you rely on any summary, this one included.

What you should not collect

The list below is a starting point. Your authorisation and your jurisdiction can add more.

  • Passwords, session tokens, API keys, or other credentials, even when they appear in a public paste. Report them to the owner through a responsible channel, and do not test them.
  • Personal data about people outside your scope, such as relatives of employees, customers, or people who commented on a post.
  • Special-category data, such as health, religion, political opinions, or sexual orientation, unless the legal basis is clear and the work genuinely needs it. Most security research does not.
  • Home addresses, personal phone numbers, and location history of individuals.
  • Content from private groups, closed chats, or accounts you reached with someone else's login.
  • Complete copies of leaked datasets. A single redacted line is enough to show a point, if you need to show one at all.
  • Photos of people where a text description answers the question.

If you collect something you should not have, stop. Record what you did and when. Tell the person accountable for the engagement. Delete the copy you should not hold, and write down the deletion.

Hands-on: write a one-page research plan

This exercise needs no lab and no commands. Choose an organisation you own or are authorised to assess. A domain in your own lab, a test company you set up, or a client that gave you written permission all work. Do not use a real person, a competitor, or a supplier you do not represent.

Copy this template into a text file and fill in every field.

text
Organisation and authorisation
  Who owns or runs the assets:
  Written permission (document name, date, who signed):
  Valid until:

Research question
  One sentence. Which decision will this support?

Purpose
  Why this data is needed, and what it will not be used for:

Scope
  In scope (domains, public repositories, public documents):
  Out of scope (people, accounts, systems, data types):

Sources and methods
  Source 1 (URL or dataset, how accessed, date):
  Source 2 (URL or dataset, how accessed, date):
  Passive only? Active steps are out of scope for this exercise.

Data minimisation
  Fields to record:
  Fields you will not record:
  Personal data expected? yes / no. If yes, the legal basis is:

Storage and retention
  Where raw material is kept, and who can access it:
  Deletion date:
  What remains after deletion (the finding and its citation only):

Review
  Reviewer name and date:

How to fill it in

A good purpose names a decision. "Learn about our company" is a topic, not a purpose. A better version reads: "Find public DNS records under example-corp.test that are missing from our asset inventory, so IT can confirm or retire them by the end of the sprint."

A good scope lists what is out as well as what is in. Writing out-of-scope items forces you to notice when a search is drifting toward a person.

For sources, name the URL or dataset and the date you accessed it. If a step touches a live system, the plan must say so and cite the authorisation. This exercise keeps everything passive.

For minimisation, list the fields you will record, then list the fields you will deliberately skip. If the plan expects personal data at all, state the legal basis.

For retention, give a real date. A plan that says "delete later" never deletes anything.

Check your plan

Read the plan back and ask whether a reviewer who did not write it could tell what you will collect, why, who can read it, and when it will be deleted. If the answer is no, rewrite the purpose first. Most other gaps follow from a vague purpose.

Common mistakes

  • Treating public as permitted. Visibility answers a technical question. The ethical question is still open.
  • Writing the purpose after the collection. A purpose written to fit existing data is a rationalisation.
  • Keeping everything in case. Storage has a cost, and so does the next person who opens the folder.
  • Building a profile for a one-fact question. If you need a domain's registrar, you do not need the owner's family tree.
  • Forgetting the deletion date. Raw material outlives the project by years.
  • Confusing the client's permission with its employees' consent. Authorisation covers the assets. It does not cover everyone who works with them.
  • Publishing identifying details in the report. Your reader needs the finding, not the personal data behind it.

How to go further

Read the Berkeley Protocol in full, and read the LGPD and GDPR texts yourself rather than relying on secondary summaries. For Brazilian guidance, check the publications of the Autoridade Nacional de Proteção de Dados (ANPD). For the EU, check the guidance of your national data protection authority.

The next article in this track, Certificate Transparency for Your Own Domains, applies these rules to a passive, scoped exercise on a domain you own. Keep your research plan open while you read it.

Sources

Sources

  1. Berkeley Protocol on Digital Open Source Investigations (OHCHR)
  2. Lei 13.709/2018 (LGPD), Planalto
  3. Regulation (EU) 2016/679 (GDPR), EUR-Lex

More in OSINT and recon