Legitimate Interest Assessment: AI PRO contact enrichment

1. Processing assessed

An AI PRO subscriber taps Enrich on one contact they saved or scanned in HeyDrop. HeyDrop sends that contact's name, email address and company name to data partners. The partner that supplies company data receives only the company name or web domain.

HeyDrop gets back:

• Person facts: job title, seniority, location and social profile URLs.
• Company facts: industry, size, founded year, headquarters, funding and website.

Partners return no phone numbers, no email addresses of any kind and no photos of people. Results are stored on that contact, are visible only to the contact's owner, and are deleted when the contact is deleted. Company facts are fetched for each enrichment and stored only on that contact; there is no shared company cache. HeyDrop keeps no copy of the inputs beyond the request, and its logs hold no personal data.

Data partners: Hunter (Data Platform) and The Companies API. People Data Labs is added only after it confirms in writing that HeyDrop may display and store its data. The current list is on the Data partners page.

Limits. Each AI PRO subscriber can enrich up to 50 contacts a month. A lookup that finds no match does not count against this quota. There is no bulk, automatic, scheduled or API enrichment. Enrich is not available on contacts that belong to a Teams workspace, and paid Teams seats do not include AI PRO.

Availability. AI PRO is available in the iOS app, in all countries, including the EU.

Notice to the person. The first time any HeyDrop user enriches a person, HeyDrop emails a short privacy notice to the contact's email address before sending their details to a data partner (Art. 14(3)(c)). The notice comes from privacy@heydrop.app, is sent through Twilio SendGrid (email delivery processor, United States), is not marketing and does not name the user ("a HeyDrop user who has your contact details"). It says what HeyDrop does, which fields are involved, the sources (with a link to the Data partners page), the legal basis and legitimate interests, retention and the person's rights, and has a one-click link to object at /legal/enrichment-opt-out. It is sent once per person, keyed on a one-way hash of the email address, and again only if the processing changes materially. HeyDrop keeps a notice log (the hash and the date sent) for as long as it needs to show compliance and avoid duplicate notices (Art. 5(2)). Enrichment requires an email address on the contact, so a notice can always be sent. The full notice text is on the Data partners page.

Objections. Before every call to a data partner, HeyDrop checks an objection list. The list holds the email address of each person who objected, plus normalised variants of that address. A person on the list is never enriched again, and existing enrichment results about them are deleted from all users' contacts within one month.

Wrong results. Under the results, the user can tap Wrong person?. This immediately deletes the result from that contact, does not count against the monthly quota, and the same lookup is not repeated for that contact. HeyDrop counts these reports without personal data, so it can monitor the wrong-match rate. The person concerned can also ask HeyDrop support to delete a wrong result.

People affected. Business contacts of AI PRO users, anywhere in the world. The GDPR applies to all of this processing under Art. 3(1), because HeyDrop is established in Poland. Lookups that find no match are in scope too, because they still disclose name, email address and company name to partners.

Out of scope:

• the subscriber's own account, billing and usage data (Art. 6(1)(b));
• sending the notice email and keeping the notice log (Art. 6(1)(c), read with Art. 5(2) and 14);
• handling objections and other requests and keeping records of them (Art. 6(1)(c));
• each data partner's collection of its own dataset, which the partner must justify itself.

2. Purpose test

• The user's interest (a third-party interest under Art. 6(1)(f); EDPB paras 19 and 20). The user wants to identify and understand a business contact they met, saved or scanned: who the person is, their role and seniority, and what their company does, so they can network and follow up in a business-to-business setting. This is the main interest. It is lawful: an ordinary business activity, protected by the freedom to conduct a business (Charter Art. 16). It is clearly articulated: one named contact and a fixed list of fields. It is real and present: it arises when the user holds the contact and taps Enrich, so it is not speculative (EDPB para 17; C-708/18 TK, para 44).
• HeyDrop's interest. HeyDrop wants to offer a paid feature that makes AI PRO worth buying. A commercial interest can be legitimate if it is lawful, judged case by case (C-621/22 KNLTB, 4 October 2024, paras 40 and 49). On its own it carries little weight. The processing stands or falls on the user's interest.
• Other interests. Data partners' revenue and general business-to-business efficiency are not relied on.
• Purposes not covered. Building a database or list of people, HeyDrop marketing to enriched people, resale, training AI models, decisions about employment, credit, insurance, housing or tenancy, sending enrichment results to AI model providers, and use within Teams. These are excluded by HeyDrop's design or banned in the Terms.

Under EDPB para 30, necessity is harder to show when the processing serves a third party's interest, and such processing is less expected by the people concerned. Steps 2 and 3 therefore decide the outcome.

Result: met.

3. Necessity test

"Necessary" means more than useful. It means the interest cannot be met as effectively by less intrusive means, judged together with data minimisation (Art. 5(1)(c); C-252/21, paras 108 and 109; EDPB paras 28 and 29). We looked at three alternatives.

• The user researches the contact manually (a search engine, the company's website, a professional network). Nothing is disclosed to partners and no third-party data is used, but it is slower and patchier. This is the weakest point of the necessity test. Enrichment is justified only as a quick substitute for what a reasonable professional would look up about a business contact, so its output must not go beyond that.
• Company-only enrichment is clearly less intrusive, because company facts are mostly not personal data. It meets part of the interest, but it cannot say who the person is or what their role is. It remains the fallback for low-confidence matches.
• Fewer fields. Job title and seniority are core to the interest. A precise location and every social profile are not.

Built into the feature:

• no phone numbers, no email addresses of any kind and no photos from partners;
• one contact at a time, only when the user taps Enrich; no bulk, automatic or scheduled refresh;
• the company-data partner receives only the company name or web domain;
• results visible only to the contact's owner and deleted with the contact;
• a monthly quota of 50 enrichments;
• a direct privacy notice to the person before any data reaches a data partner;
• one-tap removal of a wrong result by the user;
• no personal data in logs.

Limits this assessment requires (see section 5):

• Location no finer than city, region and country, never a street address.
• Social profile URLs limited to professional networks; no personal social accounts.
• Each partner gets only the inputs it needs.
• Person facts shown only above a match-confidence threshold; below it, company facts only.
• No person enrichment of role or shared addresses (for example info@ or sales@), and no company lookup for free email domains (for example gmail.com).

Result: met for this limited set of fields, provided these limits apply.

4. Balancing test

Nature of the data

The data is professional and generally of "a more public nature" (EDPB para 40). Special categories of data are not sought. Three risks remain:

• Location is a more private type of data, hence the city-level limit.
• Personal social profiles and some job titles (for example trade union, political party or religious roles) can reveal special-category data under Art. 9. That counts whenever it can objectively be inferred (C-252/21, paras 68 and 69).
• Facts about a sole trader's or a one-person company's business are personal data. This matters in Poland, where the Bisnode case concerned sole traders.

Reasonable expectations

Sources: Recital 47; C-252/21, para 112; EDPB paras 50 to 54.

• For: the person handed over a business card, or their details were scanned during a business interaction. Professionals expect a counterpart to save their details, look them up and follow up, and their professional position supports this (EDPB para 54).
• Against: the person has no relationship with HeyDrop. They are unlikely to expect an app to send their name and email address to data partners, one of them a US company, and to combine records from several sources. What is common practice in sales technology is not the test (EDPB para 52), and a notice alone does not create an expectation (EDPB para 53). Expectations are weaker still where a card was photographed without being handed over.
• Net: people expect "the person I met looks me up", not a lookup with a data partner. The safeguards must close that gap.

Transparency

HeyDrop informs each enriched person directly. The first time any user enriches a person, HeyDrop emails them a short privacy notice before their details are sent to a data partner (Art. 14(3)(c)), with a one-click link to object. The same information is published in the Privacy Policy section on contact enrichment, on the Data partners page, which also shows the full notice text, and on the opt-out page. The line under the Enrich button tells the user what is sent and to whom, and links to the Data partners page, which tells the user that the person receives a notice from HeyDrop.

• The direct notice narrows the expectations gap described above: the person learns of the processing when it starts, from HeyDrop, and can object to any further enrichment and have existing results deleted.
• The Polish supervisory authority (UODO) fined Bisnode in 2019 for not informing people directly, and the Supreme Administrative Court upheld the duty to inform directly and read the Art. 14(5)(b) exemption narrowly (NSA, III OSK 2538/21, 19 September 2023). HeyDrop holds each enriched person's email address and therefore informs them directly. HeyDrop does not rely on the Art. 14(5)(b) exemption.
• If a notice cannot be delivered (for example the address bounces), the failure is logged, and the published Privacy Policy section and Data partners page remain available.
• The notice does not name the user. It names the category of recipient ("a HeyDrop user who has your contact details"); a request for the identity of the user is handled under the rights procedure (condition 12).

Impact

Sources: EDPB paras 39 to 46.

• Accuracy. Stale data and wrong-person matches (common names, shared addresses) can attach the wrong role or employer to someone, which is a reputational risk (EDPB para 45). The user can remove a wrong result at once with Wrong person?, the same lookup is not repeated for that contact, and HeyDrop monitors the wrong-match rate. Because the person receives a notice, they can also ask HeyDrop to delete a wrong result. The risk is reduced but not removed, because the user may act on a wrong result before noticing it.
• Profiling. The result is a combined snapshot from several sources. It is narrow and professional, with no scoring and no decisions with legal or similarly significant effects (Art. 22). Eligibility uses are banned in the Terms.
• Unwanted outreach. The user already holds the email address and gains no new phone or email channel, so their reach hardly grows. Outreach remains the user's own responsibility.
• Loss of control and invisible processing. The direct notice means the processing is not invisible: the person is told before any partner receives their details. Inputs still reach partners even when there is no match, and partners might keep or reuse them to grow their datasets. Hunter's published terms say it keeps a customer's enrichment requests until the customer closes its Hunter account. This is the most serious risk. HeyDrop asks each partner to commit in writing to use the inputs only to answer HeyDrop's lookup, and confirms this with each partner before that partner receives data.
• Retention. There is no fixed maximum period for stored results; they stay until a deletion event (section 5, condition 8). The source date shown with each field and the Wrong person? removal limit the effect of stale data.
• Transfers. Some recipients, including Twilio SendGrid, which sends the notice email, are in the United States. Transfers rely on the EU-US Data Privacy Framework where the recipient is certified, otherwise on Standard Contractual Clauses.
• Not monitoring. Each lookup is one-off and triggered by the user, with no automatic refresh.
• Possible benefit to the person. Follow-up that fits their actual role.

Scale

Each user does few lookups (at most 50 a month), but the total can be large: every 1,000 subscribers can trigger up to 600,000 lookups a year (C-252/21, para 116). A DPIA is therefore required.

Vulnerable people

The people enriched are adults in a professional setting, and children are not expected. The Terms ban enriching people the user knows are children (Recital 38). The ban on eligibility decisions protects job candidates, tenants and employees.

Safeguards

Measures the GDPR requires anyway do not count as mitigating measures in the balance (EDPB para 57).

Baseline, required in any case:

• Art. 14 information, naming the legitimate interests (Art. 14(2)(b)) and the sources (Art. 14(2)(f));
• data minimisation and retention limits;
• answers to rights requests within one month (Art. 12(3));
• security and transfer safeguards;
• a DPIA, and an agreement with each partner that sets out the roles.

Additional mitigating measures, which do count:

• Objections are honoured unconditionally, with no Art. 21(1) "compelling legitimate grounds" test (EDPB para 57 gives this as an example). An objection list, keyed on the person's email address and its normalised variants, is checked before every call to a data partner. A person on the list is never enriched again, and existing results about them are deleted from all users' contacts within one month.
• Enrichment runs only when the user taps Enrich, one contact at a time, and only on people the user actually met, saved or scanned.
• Results are visible only to the contact's owner.
• A direct privacy notice to each enriched person before their details reach any data partner, with a one-click objection link, sent once per person and logged by a one-way hash of the email address.
• Wrong person? in the app deletes a wrong result at once, without using quota, and blocks the same lookup for that contact; support also deletes wrong results on request (Art. 16 and 17).
• No automatic refresh of results.
• The Terms pass restrictions on to users: internal business use only, no resale, no lists or databases of people, no AI training, no eligibility decisions, and enriching only people the user has a genuine business interaction with.
• Partners are vetted and must give lawful-sourcing warranties and an indemnity, and must not reuse HeyDrop's query inputs.

Result

With the safeguards in this assessment, the user's interest in a narrow professional snapshot of someone they actually dealt with is not overridden by the interests, rights and freedoms of the person enriched. The balance favours the processing, though not by a wide margin. Without the safeguards (above all the direct notice, the unconditional objection block, the field limits, the Wrong person? removal and the partner controls), the lack of any relationship with HeyDrop and the third-party origin of the data would likely tip the balance against HeyDrop. With them, the person is informed directly before any disclosure, can object with one click, and wrong results can be removed at once. The point most open to challenge is the use of partners' third-party data, which HeyDrop addresses through the partner controls.

5. Conclusion

HeyDrop relies on Art. 6(1)(f) GDPR for contact enrichment. The balance favours the processing on the conditions below, all of which are met. If a condition stops being met, person enrichment does not run until it is restored. Company-only enrichment would need its own, shorter check.

1. Public information. The Privacy Policy section on contact enrichment, the Data partners page (including the full notice text), the opt-out page and the AI PRO section of the Terms are published, and the line under the Enrich button says what is sent and to whom and links to the Data partners page.
2. Email address as key. Enrichment uses the contact's email address as a required input, as the address for the notice and as the key for the objection check.
3. Direct notice. The first time any user enriches a person, the privacy notice is emailed to the contact's address before any data is sent to a data partner; once per person, keyed on a one-way hash of the email address, and again only if the processing changes materially; the notice log holds only the hash and the date sent; bounces and delivery failures are logged.
4. Objection list. The objection list (email address plus normalised variants) is checked before every notice and every call to a data partner; objecting people are never enriched again; existing results about them are deleted from all users' contacts within one month; the opt-out page is live.
5. Field allowlist, enforced on the server. No phone numbers, email addresses or photos; location no finer than city, region and country; professional-network profile URLs only.
6. Minimised inputs. Each partner receives only the inputs it needs (company name or web domain only for the company-data partner); a match-confidence threshold applies; no person enrichment of role or shared addresses; no company lookup for free email domains.
7. Source per field. The partner that supplied each field, and the date, are stored with the result, so that access requests can be answered (Art. 14(2)(f), 15(1)(g)).
8. Deletion and wrong results. Results are deleted with the contact, with the user's account (within 30 days), on objection or erasure, and at once when the user taps Wrong person?, which does not use quota and blocks the same lookup for that contact; there is no automatic refresh.
9. Access and use limits. Owner-only visibility; no bulk, automatic or API enrichment; the 50-a-month quota and abuse throttling; Enrich blocked on contacts that belong to a Teams workspace.
10. Partner controls, before each partner goes live. Written display and storage rights (People Data Labs stays off until it confirms in writing); an agreement setting out the roles; a lawful-sourcing warranty and indemnity; a written commitment that HeyDrop's query inputs are used only to answer the lookup; a process for deletion and opt-out notices; a transfer mechanism (Data Privacy Framework or Standard Contractual Clauses).
11. No AI model providers. Enrichment results are not sent to AI model providers, and logs are checked to confirm they hold no personal data.
12. Rights procedure. Requests from enriched people are answered within one month. It covers how to answer a request for the identity of specific recipients, which may mean naming the user who enriched the person (C-154/21 Österreichische Post), and how support handles wrong-person reports from the person or the user (Art. 16 and 17).
13. Records. The DPIA is approved and the record of processing activities (Art. 30) is updated.