A privacy checklist for phone and e-mail checks

Before you check phone numbers or e-mail addresses, decide why you're checking, which lawful basis covers it, which checks you actually need, how long you'll keep the results, and how you'll handle objections and requests from the people concerned. Then make sure your provider contract, logging and masking match those decisions. The checklist below walks through each point with the GDPR article it comes from.

This is not legal advice. It describes common practice under the EU GDPR. The UK GDPR and other laws have similar ideas but differ in detail, and your sector may add its own rules. Consult your counsel for your specific case.

#Is checking a number or address processing personal data?

Usually, yes. The GDPR defines personal data as any information relating to an identified or identifiable natural person (Article 4(1)). A mobile number or a personal e-mail address normally qualifies. "Processing" covers almost anything you do with it, including consultation, use and disclosure by transmission (Article 4(2)). Sending a number to a check API and storing the answer is processing.

The answer can also be personal data, and some answers reveal more than others. "This number is a mobile line" says little about a person. "This address has an account on service X" says more. That difference should shape which checks you run, as our comparison of e-mail verification and account existence checks explains.

#1. Have you written down the purpose?

Write one sentence per purpose, before the first check. Article 5(1)(b) requires personal data to be collected for "specified, explicit and legitimate purposes" and not further processed in an incompatible way (purpose limitation).

Good purpose statements are specific:

• "Screen new sign-ups for fake or high-risk phone numbers before sending a passcode."
• "Remove unreachable numbers from our customer list before a service announcement customers opted into."
• "Choose the messaging channel for order updates a customer asked to receive."

Vague purposes such as "enrich our data" or "understand our customers better" make every later question harder. Checks run for fraud prevention shouldn't quietly feed marketing segments later. That would be a new purpose, and it needs its own assessment.

#2. Which lawful basis applies?

Pick one per purpose and document why. Article 6(1) lists six bases. For contact-data checks, three come up most often:

On legitimate interests, Recital 47 says processing strictly necessary for preventing fraud "also constitutes a legitimate interest of the data controller concerned". The European Data Protection Board adds that this isn't automatic. In its Guidelines 1/2024, it sets out three cumulative conditions: a legitimate interest, the need to process personal data for that interest, and a balance in which the person's interests and rights don't take precedence. Controllers should assess and document these before processing (EDPB, 2024). A short legitimate interests assessment per purpose is the usual way to show that.

#3. Are you requesting only the checks you need?

Run the smallest set of checks that serves the purpose. Article 5(1)(c) requires data to be "adequate, relevant and limited to what is necessary" (data minimisation), and Article 25 asks for data protection by design and by default.

In practice:

• Choose checks per purpose, not per record. A pre-send SMS check may need only line type. A sign-up risk check may add messaging presence. Few purposes need every check.
• Prefer less revealing checks. A mailbox check says an address works. An account existence check says the person uses a service. Use the second only where the risk justifies it.
• Skip what you already know. Don't re-check a number you checked last week for the same purpose. With MobileValidate, repeat checks inside the freshness window come from your account's cache and aren't billed, but the better habit is not to ask again.
• Don't send what the check doesn't need. Our API takes the identifier and the check code. It doesn't need names, and it never returns names, photos or profiles.
• Clean input first. Malformed and duplicate entries are flagged (invalid_number, duplicate) and never checked, so they go no further than the validation step. You're not charged for inconclusive results (unknown, unsupported country, timeout, invalid, duplicate) either.

#4. How long will you keep inputs and results?

Decide a retention period per data type, and make sure your systems actually delete. Article 5(1)(e) requires data to be kept no longer than necessary (storage limitation), and Article 30(1)(f) asks controllers to record, where possible, the envisaged time limits for erasure.

A common pattern:

On the provider side, check the defaults and your options. MobileValidate keeps real-time lookups for 7 days and bulk jobs for 30 days by default. Bulk retention can be set from 1 day to 24 months, and DELETE /v1/jobs/{id} purges a finished job's results at once. See the trust page.

#5. How will you handle objections and suppression?

Give people a way to object, and make sure an objection stops future checks everywhere. Article 21(1) gives people the right to object to processing based on legitimate interests. You must then stop unless you demonstrate compelling legitimate grounds that override their interests, rights and freedoms, or the processing is needed for legal claims. For direct marketing, Article 21(3) is absolute: once someone objects, the data can no longer be processed for that purpose.

What this means in your systems:

• Keep a suppression list keyed on the normalized identifier (E.164 for numbers, lowercased for e-mails), and check it before calling any API.
• Honour provider-side objections too. People can object to MobileValidate checks through our opt-out form. Suppressed identifiers come back as suppressed, aren't checked and aren't charged.
• Don't let suppression leak information. Our opt-out form replies the same way in every case, so it never confirms whether we hold data about someone.

#6. Can you answer data-subject requests on time?

Know where check results live, so you can answer access and erasure requests within the deadline. Article 12(3) requires a response without undue delay and in any event within one month, extendable by two further months for complex or numerous requests.

• Access (Article 15). Be able to say whether you checked someone's number, for what purpose, which categories of recipient received it (for example, a verification provider) and how long you keep it.
• Erasure (Article 17). Applies, among other grounds, when data is no longer necessary for its purpose or after a successful objection. Delete the stored decision and ask your provider to delete anything it holds for you.
• Assistance from your provider. Under Article 28(3)(e), processors must help controllers respond to these requests.

Our data-subject notice explains how individuals can contact us directly.

#7. What does your privacy notice say?

Tell people you check their contact details and why, in plain language. Article 13 requires information at the time you collect data from the person, including the purposes and the legal basis. Article 14 covers data you obtained elsewhere.

A sentence such as "We verify phone numbers and e-mail addresses with specialist providers to prevent fraud, keep accounts secure and make sure our messages reach you" covers most sign-up and messaging uses. If you rely on legitimate interests, say so, and say how people can object.

#8. Does your provider contract meet Article 28?

Sign a data processing agreement with every check provider. Article 28(3) requires a contract that, among other things, has the processor act only on your documented instructions, keep staff under confidentiality, secure the data under Article 32, assist you with data-subject requests, and delete or return the data at the end. Article 28(2) requires your authorisation before the processor engages other processors, with notice of changes so you can object.

Ask each provider for:

• the DPA itself, and how sub-processors are disclosed and changed;
• where data is processed, and the transfer mechanism if it leaves the EEA;
• default retention and deletion options;
• how they handle objections from individuals.

MobileValidate's DPA is available on request. We publish sub-processor categories, and customers who sign the DPA receive the named list under confidentiality, with notice before changes. Our buyer's guide lists more provider questions.

#9. Are identifiers masked in logs and tools?

Keep full numbers and addresses out of places that don't need them. Article 32 asks for security appropriate to the risk, naming pseudonymisation and encryption as examples.

• Never put identifiers in URLs or headers. They end up in proxy and access logs. Our API accepts them only in request bodies.
• Mask in logs, dashboards and exports. For example +44770*****01 and re•••@example.com, which is how our job results and downloads show them.
• Log decisions, not responses. A decision code and checked_at are enough for debugging and audits.
• Limit who can see raw data, and use scoped API keys with IP allowlists where possible.

#10. Do you need a DPIA?

Possibly, if you check at scale or combine results in new ways. Article 35 requires a data protection impact assessment where processing, in particular using new technologies, is likely to result in a high risk to people's rights and freedoms. Screening large volumes of sign-ups, combining many checks into automated decisions, or checking people who never dealt with you are all reasons to ask the question. Your counsel or data protection officer can tell you whether it applies.

#What does the whole checklist look like?

#What are the key takeaways?

• Checking a phone number or e-mail address is usually processing of personal data, and some answers reveal more than others.
• Write the purpose down, choose and document a lawful basis, and run only the checks that purpose needs.
• Keep decisions and dates rather than raw responses, set retention periods, and test that deletion works.
• Honour objections with a suppression list checked before every call, and be ready to answer access and erasure requests within a month.
• Sign an Article 28 DPA with every provider, and keep identifiers out of URLs and logs.
• This checklist isn't legal advice. Consult your counsel, and see our trust page for how MobileValidate handles its side.