Data protection impact assessment: AI PRO contact enrichment

1. Description of the processing (Art. 35(7)(a))

Nature. A paying AI PRO subscriber taps Enrich on one contact they saved or scanned. The first time any user enriches a person, HeyDrop emails that person a short privacy notice. HeyDrop then sends the contact's name, email address and company name to data partners and stores the returned business facts on that contact, visible only to its owner. There is no bulk or automatic enrichment.

Scale. Up to 50 enrichments per subscriber per month (at most 600 a year). A lookup that finds no match does not count against the limit, and neither does a result the user removes with Wrong person?. Planning assumption at scale: 10,000 to 50,000 lookups a month, up to about 600,000 lookups a year, and at most one notice email per enriched person. Enriched people can be anywhere (US, UK, EU, Gulf states and elsewhere). The GDPR applies to all of it, because HeyDrop is established in Poland (Art. 3(1)).

Context. Enriched people gave a card to, or were scanned by, the user. They have no relationship with HeyDrop and do not expect third-party lookups. The sector is under active enforcement: Lusha (Garante, €2M and a ban in Italy, legitimate interest rejected, July 2026), Kaspr (CNIL, €240k), Bisnode (UODO 2019, upheld by the Polish Supreme Administrative Court, NSA III OSK 2538/21, on the duty to notify people directly under Art. 14).

Purposes. (a) Let the user know who a business contact is and what their company does, for professional networking and business-to-business follow-up. (b) Offer this feature in AI PRO. (c) Inform enriched people directly (Art. 14) and be able to show that HeyDrop did so (Art. 5(2)). These are not purposes: HeyDrop's own marketing or sales, building a database of people, training models, or sharing results with other users.

1.1 Data flow

1. Tap Enrich. The line under the Enrich button says that Enrich sends the contact's name, email address and company name to HeyDrop's data partners, and links to the Data partners page, which also tells the user that the person receives a short privacy notice from HeyDrop (App Store guideline 5.1.2(i) and (v)). Before any lookup, the backend checks that AI PRO is active and quota is left, that the contact has an email address, and that the contact does not belong to a Teams workspace.
2. Objection check. The backend checks the person's email address, normalised, against HeyDrop's objection list before every call to a data partner. If the address is on the list, enrichment stops: no notice is sent, no partner is called and nothing is stored. The user sees a neutral message that does not reveal the objection.
3. Notice email (Art. 14(3)(c)). The backend computes a one-way hash of the normalised email address and looks it up in the notice log. If the person has not been notified before, HeyDrop sends the privacy notice to the contact's email address before any data is sent to a data partner. The notice is sent from privacy@heydrop.app through Twilio SendGrid (email delivery processor, United States) on a separate, low-volume transactional stream. It is not marketing and does not name the user ("a HeyDrop user who has your contact details"). It says what HeyDrop does, the fields, the sources (with a link to the Data partners page), the legal basis and legitimate interests, retention and the person's rights, and it has a one-click link to object at /legal/enrichment-opt-out. The full text is published on the Data partners page. HeyDrop records the hash and the date sent in the notice log. The notice is sent once per person, whichever user enriches them, and again only if the processing changes materially. Bounces and delivery failures are logged.
4. Company step. HeyDrop sends only the company name or web domain to the company-data partner (The Companies API). Company facts are fetched for each enrichment and stored only on that contact. There is no shared company cache.
5. Person step. HeyDrop sends name, email address and company name to the person-data partners (Hunter; People Data Labs only after it confirms in writing that HeyDrop may display and store its data) over TLS. Partners return job title, seniority, location and social profile URLs, or no match.
6. Filter and store. HeyDrop keeps only allowlisted fields, drops low-confidence matches and records the source partner and date for each field (Art. 14(2)(f), 15(1)(g)). Results are stored on the contact (AWS, United States, AES-256 with KMS). Inputs are not kept beyond the request. Logs hold no personal data, and Engineering tests that pseudonymous identifiers do not reach the logs either, because they are still personal data (Recital 26).
7. Display and Wrong person? Only the owner sees the results, in the app, labelled as coming from data partners, with the date. Under the results the user can tap Wrong person?. This immediately deletes the result from that contact, does not count against the monthly limit, and the same lookup is not repeated for that contact. HeyDrop counts the report without personal data, so it can monitor the wrong-match rate.
8. Later use by the user, for example a follow-up email, is under the user's own control and bound by the restrictions in the Terms.
9. Deletion paths. The user taps Wrong person?; the user deletes the contact; support deletes a wrong result on request; the user's account is deleted (removed within 30 days); the person objects or asks for erasure (results about them are deleted from all users' contacts within one month); a data partner sends a deletion notice. If the user's AI PRO plan ends, existing results stay on the contact and no new enrichments run.
10. Objections. The person uses the link in the notice email, the opt-out page or writes to privacy@heydrop.app. The request opens a support conversation. Support asks the person to confirm by replying from the same email address (Art. 12(6)), then adds the address to the objection list and deletes existing results about the person from all users' contacts within one month (Art. 12(3), 17(1)(c), 21). The person is told how to opt out with each data partner directly.

1.2 Data inventory

1.3 Data subjects and roles

Data subjects. (1) Enriched people: business contacts of AI PRO subscribers, mostly professionals, in any country. Children are not expected; the Terms forbid enriching people the user knows are under 16. (2) AI PRO subscribers. (3) People who object or exercise rights, some of whom were never enriched. Founders and investors named in company data are excluded by design (M7).

Roles. HeyDrop is the independent controller of the enrichment processing: the lookup, disclosure to partners, storage of results, the notice email and notice log, and objection handling. The user is a separate controller of their own contact list and of what they do with results. The household exemption may cover a user acting purely personally, but never HeyDrop (Recital 18). Joint controllership with the user (Art. 26; CJEU C-40/17, C-210/16) is the main alternative reading; HeyDrop handles transparency and rights requests either way, and the Terms say so. Data partners are most likely independent controllers of the data they return and possibly processors for the inputs; HeyDrop fixes each partner's role in its contract before that partner goes live. Twilio SendGrid is HeyDrop's processor for sending notice emails. Enrichment is not part of the Teams processor service, and data partners are not Teams sub-processors.

2. Why a DPIA is needed

None of the Art. 35(3) cases applies directly. A DPIA is required under Art. 35(1) and the UODO list issued under Art. 35(4), because the processing meets two or more criteria. Both the WP248 rev.01 guidelines and the UODO list say that two criteria will in most cases require a DPIA.

Invisible processing. Data not obtained from the person is not a separate WP248 criterion. It feeds criterion 6 (reasonable expectations) and is a separate criterion on the UK ICO list. HeyDrop treats invisibility as a core risk (R1) and addresses it with the direct notice email.

UODO list (Komunikat Prezesa UODO z 17 czerwca 2019 r., M.P. 2019 poz. 666).

• Item 8, comparisons, evaluation or inference from data obtained from different sources: met. Its examples include marketing firms extending profiles of potential customers and creating profiles from datasets from different sources.
• Item 7, large scale (number of people, range of data, retention, geographic extent): likely met.
• Item 10, innovative technological solutions: arguably met (AI PRO context).
• Item 1, profiling with negative effects (example: profiling app users to send commercial information): borderline, because users may use results for sales outreach.
• Item 12, location data: not met, because location stays at city, region or country level and is static (M7).

At least two items are met, so the DPIA is mandatory.

3. Consultation (Art. 35(2), (9))

HeyDrop's data protection officer (dpo@heydrop.app) was consulted on this assessment, which is approved by the HeyDrop P.S.A. management board.

• Engineering reviewed the data flow, field allowlist, objection check, notice email and notice log, Wrong person? removal, logs and deletion paths.
• Data partners answer HeyDrop's vendor questions on roles, sourcing, retention of inputs, transfers and deletion notices; the answers feed M11 and M12.
• Data subjects' views (Art. 35(9)). HeyDrop does not consult enriched people in advance, because they have no relationship with HeyDrop and cannot be identified before they are enriched. Instead HeyDrop tracks objections (including those made through the notice email), complaints, notice delivery failures and the wrong-match rate, and reviews them every three months (M22).

4. Necessity and proportionality (Art. 35(7)(b))

• Lawful basis. Art. 6(1)(f) for enrichment (see the Legitimate interest assessment); Art. 6(1)(b) for the subscriber's own data; Art. 6(1)(c) for sending the notice email and keeping the notice log (Art. 5(2), 14) and for handling objections and other requests and keeping records of them (Art. 5(2), 12, 21). Consent is not used, because HeyDrop has no relationship with the person through which to ask for it. Differences from Lusha: no database of people, one contact the user already holds, business facts only, a direct notice before any partner call, a technical objection block, no phone numbers or email addresses returned. The Garante's rejection of legitimate interest in the Lusha case remains a relevant precedent, and HeyDrop's safeguards are designed around it.
• Purpose limitation. Results serve only the contact's owner. HeyDrop does not use results, notice log entries or objection records for its own marketing, sales targeting or model training (M17). The notice email carries no marketing.
• Minimisation. Inputs: name, email address and company name only. Outputs: a fixed allowlist. No phone numbers, no email addresses of any kind, no photos. Location no finer than city, region or country; social URLs limited to professional profiles; funding limited to round, amount and date, with no names of people (M7). The notice log holds only a one-way hash of the email address and the date sent. Wrong-person reports are counted without personal data.
• Accuracy (Art. 5(1)(d)). Email-keyed matching, a confidence threshold, source and date shown with each field, the in-app Wrong person? removal, and rectification and deletion on request through support (M9, M19, M23). Because the notice reaches the person, they can also report a wrong result themselves.
• Storage limitation (Art. 5(1)(e)). Results live only as long as the contact, the account and the absence of an objection, and are removed at once when the user taps Wrong person?. There is no fixed maximum age for results (R10). The notice log is kept only as long as HeyDrop needs it to show compliance and avoid duplicate notices.
• Transparency (Art. 12 to 14). HeyDrop informs each enriched person directly: the notice email is sent to the contact's email address the first time any user enriches them, before their details are disclosed to a data partner (Art. 14(3)(c)). Enrich requires an email address, so a notice can always be sent. The same information is published in the Privacy Policy, on the Data partners page, with the full notice text, and on the opt-out page. HeyDrop does not rely on the Art. 14(5)(b) exemption, which Polish case law reads narrowly when the controller holds a contact address (Bisnode; NSA III OSK 2538/21). The public texts are the fallback where a notice cannot be delivered (R12).
• Rights (Art. 15 to 22). Access (fields, source per field, recipients), rectification, erasure, restriction and objection. The notice email has a one-click link to object. After an objection, the person is never enriched again and existing results about them are deleted from all users' contacts within one month. The contact entry a user created themselves (name, email, company) stays, because it is the user's own record. Complaints go to UODO or the authority where the person lives or works. Deadline: one month (Art. 12(3)).
• Partners and transfers (Chapter V). AWS (United States), Intercom (United States), Twilio SendGrid (United States, email delivery), People Data Labs (United States, only after its written confirmation), Hunter (US company with servers in Belgium; its privacy policy cites Standard Contractual Clauses and the UK IDTA), The Companies API (France according to its privacy policy; no Chapter V transfer if it hosts data in the EEA). HeyDrop checks each recipient's EU-US Data Privacy Framework certification before that recipient receives data and uses Standard Contractual Clauses (Module 1, or Module 2 or 3 by role) with a transfer impact assessment where a recipient is not certified. For UK data: the UK Extension to the Data Privacy Framework, or the UK IDTA or Addendum.
• By design and by default (Art. 25). Objection check before every notice and partner call; notice before any disclosure to partners; inputs not stored; owner-only display; one-tap removal of wrong results; results deleted with the contact; no personal data in logs; no bulk, automation or API access; every returned field off unless allowlisted.

5. Risk register (Art. 35(7)(c))

Likelihood (L): 1 remote, 2 possible, 3 likely. Severity (S): 1 limited, 2 significant, 3 severe. Level = L × S: 1 to 2 Low, 3 to 4 Medium, 6 to 9 High. Inherent means before measures. Measures are listed in section 6.

6. Measures (Art. 35(7)(d))

7. Residual risk and conclusion

With the direct notice email (M8), the notice log (M24) and the objection list (M5) in place, R1 drops from High to Low and R9 from High to Low. With the in-app Wrong person? removal (M19), R2 drops from High to Medium. R12 (notices not delivered) is Low: failures are logged and reviewed, and the published Privacy Policy section and Data partners page remain available to everyone.

Remaining Medium risks:

• R2, wrong-person matches. Matching errors cannot be removed entirely, but the user can delete a wrong result with one tap, the person learns of the enrichment from the notice and can report a wrong result, and HeyDrop monitors the wrong-match rate.
• R3, partner sourcing. HeyDrop cannot audit partners' supply chains; it relies on contractual warranties, Hunter's public-web sourcing and partners' own opt-out handling.
• R5, user misuse. Reduced by the quota, the Terms and anomaly alerts.
• R10, stale data. There is no fixed maximum age for results; the source date shown with each field and Wrong person? limit the impact.
• R13, CJEU C-154/21. Legal uncertainty about naming the user who enriched a person, handled case by case under M18.
• R17, partner use of inputs. Addressed through each partner's written commitments.

Conclusion. No residual risk is rated High. With the measures in section 6, the processing may proceed without prior consultation of UODO under Art. 36 GDPR. HeyDrop repeats this assessment if People Data Labs or any other partner would go live without written display and storage rights or lawful-sourcing warranties, if enrichment data would enter AI model features without M16, or if the review under M22 shows that a residual risk has risen.