Yes. Nothing in the GDPR treats public availability as a defence. If the data identifies a living person, it is personal data whether you collected it from a signup form or from a public profile page, and every obligation follows it. The part most teams miss is not the lawful basis. It is Article 14, which says you have to tell people you hold their data even though you never met them.
This article covers why public does not mean non-personal, what lawful basis scraping actually runs on, the Article 14 duty and its one-month clock, how narrow the disproportionate-effort exception really is, and where this bites inside a normal B2B SaaS.
Public Availability Is Not A Property Of The Data
Article 4(1) defines personal data as information relating to an identified or identifiable natural person. There is no clause about where you found it. Recital 26 sets the identifiability test — whether identification is reasonably likely using means available to you or to anyone else — and that test is indifferent to whether the source page required a login.
A public LinkedIn profile, a company team page, a GitHub commit history, a conference speaker list and a review with a display name are all personal data. So is a business email address in the form firstname.lastname@company.com, which is the format most scraped B2B lists are made of.
The practical consequence is that scraping does not create a special category of lower-obligation data. It creates ordinary personal data with a worse paper trail, because you have no signup record, no consent log and no timestamp for when the person entered your systems.
One thing this article does not cover: training machine-learning models on scraped corpora is a different question with its own developing guidance, and none of the reasoning below is intended to answer it.
Your Lawful Basis Is Article 6, And It Is Rarely Consent
You cannot obtain consent from someone who does not know you exist, so scraping runs on Article 6(1)(f), legitimate interests, or it runs on nothing. That means a documented balancing test before collection, not a rationalisation afterwards.
The balancing test is harder for scraped data than for data someone handed you, and the reason is reasonable expectations. A person who published their work email on a company site expects to be contacted about that company's business. They do not necessarily expect to be enriched, scored, profiled against firmographic data and held for three years.
Two constraints do real work here. Article 5(1)(b) purpose limitation means the interest you documented is the only one you may pursue — a list collected to research a market cannot quietly become a sales list. And Article 21 gives an unqualified right to object where processing is for direct marketing, with no balancing exercise available to you at that point. Where scraped contact data is used for outreach, separate marketing rules apply on top of the GDPR analysis; that is its own subject and this article does not attempt it.
Article 14 Is The Obligation Almost Everyone Skips
When personal data is obtained from someone other than the data subject, Article 14 rather than Article 13 applies, and it carries a timing obligation Article 13 does not: within a reasonable period after obtaining the data and at the latest within one month, or at the point of first communication with the person if that comes sooner.
Article 14 also requires something Article 13 does not — under 14(2)(f) you must tell the person the source the data came from, and whether it came from a publicly accessible source. That is a specific disclosure about your scraping, not a generic line in a privacy notice.
The information itself is the same set that any privacy notice or privacy policy has to carry: identity, purposes, lawful basis, recipients, retention, rights. What changes is that you have to actively deliver it to people who never visited your site, and you have to do it on a clock.
The Disproportionate-Effort Exception Is Narrower Than Its Reputation
Article 14(5)(b) lifts the obligation where providing the information proves impossible or would involve a disproportionate effort. This is the provision scraping operations lean on, and it is read far more restrictively than most teams assume.
The text itself narrows it. It names the situations it has in mind — archiving in the public interest, scientific or historical research, statistical purposes, subject to the Article 89(1) safeguards — and commercial lead generation is not among them. Recital 62 gives the three factors to weigh: the number of data subjects, the age of the data, and any appropriate safeguards you have adopted.
Read those three factors honestly and a typical B2B scrape fails. The dataset is small enough to notify, the data is recent, and you hold the person's email address, which makes notification not merely possible but cheap. Impossibility is not the same as inconvenience.
Where the exception genuinely applies, it is not a free pass either. You are expected to document the assessment per project rather than adopt it as policy, and to publish a public notice describing the scraping. UK readers should note separately that the Data (Use and Access) Act 2025 restructures these transparency exceptions in UK GDPR, including a route in Article 13 that EU GDPR does not have. We have not verified which of those provisions are in force as at 8 August 2026, and the commencement is staged — confirm the current position with the ICO before relying on it.
Where This Actually Bites In A B2B SaaS
Most SaaS companies scrape without calling it scraping. An enrichment vendor appends firmographic and contact data to your signups. A competitor-monitoring script pulls pricing pages that carry named testimonials. A support tool ingests public review sites. A hiring workflow collects candidate profiles from public sources.
Each of those is Article 14 territory, and in the enrichment case there is a second problem: your vendor obtained the data, so you need to know their source to make your own 14(2)(f) disclosure. Most enrichment contracts do not tell you, and the ones that do describe it in a way that would not survive being read out to a regulator.
The work email addresses that make up these lists are the clearest case, because the identifiability question is settled and the volume is high. And every one of these flows belongs in your record of processing activities, listed with its source, its basis and its retention period, which is usually the point at which somebody notices the list has been sitting there since 2023.
Common Mistakes With Scraped Personal Data
Treating public as a lawful basis. Public availability is a fact about the source, not a legal ground. You still need one of the six bases in Article 6, and you still need to be able to name which one before you collect anything.
Writing the legitimate interests assessment after the scrape. A balancing test produced in response to a complaint is evidence of the problem, not a defence. It has to exist before collection, name the specific interest, and be revisited when the purpose changes.
Assuming Article 14 does not apply because there was no relationship. The absence of a relationship is precisely what triggers Article 14 rather than Article 13. Having never spoken to the person is the condition for the obligation, not an exemption from it.
Invoking disproportionate effort as a blanket policy. The exception is assessed per project against the number of people, the age of the data and your safeguards. Applying it to every dataset by default is the pattern regulators look for.
Keeping scraped records indefinitely because they cost nothing to store. Storage limitation under Article 5(1)(e) applies to data you never asked for as much as to customer data. A scraped list with no retention period is an accumulating liability attached to people who do not know you hold it.
FAQ
Does GDPR apply if I only scrape company information, not people?
Company data about a legal person is outside the GDPR under Recital 14. In practice the two are rarely separable — a company page carries named staff, direct dial numbers and individual email addresses, and those are personal data. If your scrape returns anything attached to a named human, treat the dataset as personal data.
Do I have to notify every person on a scraped list individually?
That is the default under Article 14, within one month or at first contact if sooner. You can be relieved of it where notification is genuinely impossible or disproportionate, but that is a per-project assessment weighing the number of people, the age of the data and your safeguards — not a standing policy, and not satisfied by a privacy page nobody is directed to.
Is scraping data that someone deliberately made public still a privacy issue?
Yes, because publishing data for one purpose is not agreement to every other purpose. Someone who put their email on a company site to receive customer enquiries has not agreed to be added to a prospecting database. Purpose limitation under Article 5(1)(b) is the provision that carries the point.
What if a vendor does the scraping and sells me the list?
You are a controller for what you then do with it, and your Article 14 obligations are yours rather than theirs. You need to know the source well enough to disclose it under 14(2)(f), and you need contractual assurance about how the data was obtained. If the vendor will not tell you, you cannot comply, and that is a reason not to buy the list.
Closing Thought
The uncomfortable part of Article 14 is that it is the one obligation that makes scraping visible to the people you scraped. Every other requirement can be met internally — write the assessment, set the retention period, secure the store — and nobody outside the company ever knows. Notification is different. It tells a stranger you have been holding their data, and it invites them to object. That is not an accident of drafting. It is the point of the provision, and it is why the disproportionate-effort exception gets argued so hard by people whose real objection is not the effort.
If your prospecting, enrichment or research flows are the ones nobody has mapped yet, the fix starts with writing them down rather than buying anything. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request handling and security page, which makes the answering side of this easier when a buyer or a data subject asks. It does not build your Article 30 record for you, decide your lawful basis, or notify a scraped list — those are judgement calls that stay with you.