Guides

Is a phone number personal data under the GDPR?

When a phone number is personal data under the GDPR, what changes for business numbers, and how lookups and enrichment fit lawful basis, notice and rights.

By Published 10 min read

On this page

In most cases, yes. A phone number that belongs to a person, or can be linked to one with reasonable effort, is personal data under Article 4(1) GDPR. That includes most mobile numbers, sole traders' numbers and employees' direct lines. A company switchboard usually isn't. The result of a lookup on a personal number is personal data too.

This is not legal advice. It explains how the GDPR text and the case law of the EU Court of Justice are commonly read, applied to phone-number lookups and enrichment. The UK GDPR and national laws differ in detail. Consult your counsel for your own case. For a step-by-step compliance list, see our privacy checklist for phone and e-mail checks. This article goes one level deeper on the questions that come before it.

What does the GDPR say counts as personal data?

The GDPR defines personal data in Article 4(1) as "any information relating to an identified or identifiable natural person". A person is identifiable if they "can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier" or other factors.

Recital 26 explains how to test identifiability. You take account of "all the means reasonably likely to be used, such as singling out, either by the controller or by another person". Relevant factors include "the costs of and the amount of time required for identification", given the technology available at the time. Anonymous information, where the person is not or no longer identifiable, falls outside the regulation.

A phone number is a textbook identifier. It is usually unique, it is often tied to one person for years, and it can be linked to a name through contracts, contact lists, messaging apps or a simple call. For a mobile number, the link to one individual is usually direct. That's why regulators and courts treat most phone numbers as personal data without much debate.

A security seal with a shield, an encrypted-storage lock, a masked phone number and a retention timer.A security seal with a shield, an encrypted-storage lock, a masked phone number and a retention timer.
Numbers are encrypted at rest, masked in logs and screens, and kept only as long as needed.

Does it matter who can identify the person?

Yes, and two judgments of the Court of Justice shape the answer.

In Breyer (C-582/14, 19 October 2016), decided under the GDPR's predecessor, Directive 95/46, the Court held that a dynamic IP address stored by a website operator was personal data for that operator where it "has the legal means which enable it to identify the data subject with additional data" held by the internet provider (CJEU, 2016). It added that a means of identification is not "likely reasonably to be used" if identification is prohibited by law or practically impossible because it requires "a disproportionate effort in terms of time, cost and man-power, so that the risk of identification appears in reality to be insignificant" (paragraphs 45 and 46). The additional information doesn't have to sit with one party.

In EDPS v SRB (C-413/23 P, 4 September 2025), the Court looked at pseudonymised data passed to a third party. It held that the existence of additional information does not mean that such data must be regarded "as constituting, in all cases and for every person, personal data", because pseudonymisation may prevent persons other than the controller from identifying anyone. It also held that the controller's own duty to inform people is assessed from the controller's point of view, at the time of collection (CJEU, 2025). The case concerned the EU institutions' data protection regulation (2018/1725), whose definitions mirror the GDPR's.

For phone numbers the practical lesson is simple. The business that holds the number almost always knows whose it is. For that business, the number and anything learned about it are personal data.

Are business phone numbers personal data?

It depends on whether the number relates to a legal person or to a natural person. Recital 14 says the GDPR "does not cover the processing of personal data which concerns legal persons", including "the contact details of the legal person".

NumberUsually personal data?Why
Company switchboard or general support lineUsually notContact detail of a legal person (Recital 14)
Shared department line (e.g. sales desk)Often not, but checkRelates to the company, unless one person answers it
Employee's direct dial or work mobileYesRelates to an identifiable employee
Sole trader's or freelancer's numberYesThe business and the person are the same
Personal mobile used for a business accountYesRelates to the individual
Number in a B2B lead list with a contact nameYesLinked to a named person

Two cautions apply. First, a list rarely says which kind each number is. A B2B list is usually a mix, and many small businesses run on the owner's mobile. Second, the line type doesn't settle the question. A mobile number can be a company's shared phone, and a fixed line can be one person's home. When you can't tell, treat the number as personal data. The cost of that assumption is low, and the cost of the opposite mistake is higher.

Is a hashed or masked phone number still personal data?

Usually, yes, for the business that did the hashing. Article 4(5) defines pseudonymisation as processing data so it can no longer be attributed to a person "without the use of additional information", kept separately. Recital 26 says pseudonymised data that "could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person".

Phone numbers are also a weak case for hashing. A country has only a limited set of possible numbers, so an unsalted hash can often be reversed by hashing every candidate and comparing. A keyed hash (with a secret key) is much better, and it's how we store identifiers ourselves. It is still pseudonymisation, not anonymisation.

Masking works the same way. A number shown as +44770*****01 in a log is safer to handle. But if the full number sits elsewhere in the same system, the masked value is still personal data. Masking reduces risk; it doesn't take you outside the regulation.

Is a lookup or enrichment "processing"?

Yes. Article 4(2) defines processing as any operation on personal data, including "consultation, use, disclosure by transmission" and "alignment or combination". A number lookup touches several of these at once:

  1. Transmission. You send the number to a lookup provider.
  2. Creation of new data. The provider returns facts about the number: line type, carrier, porting, whether an account exists on a messaging app, a spam-report level.
  3. Combination. You attach those facts to your customer record.

The answer is personal data too. "This number is a mobile line on carrier X" or "this number has a messaging account" relates to the person who holds the number. Some answers reveal more than others: an account on a specific service says more about a person's life than a line type. That difference should shape which checks you run. Our comparison of e-mail verification and account existence checks walks through it.

Roles matter as well. When you send numbers to a provider to answer your question, you are normally the controller and the provider acts as your processor under an Article 28 contract. A provider can also be a controller for data it compiles itself, such as spam-report data. Our data-subject notice explains which role we take for which check, and our DPA covers the processor side.

Which lawful basis fits a phone lookup?

Every purpose needs one of the six bases in Article 6(1). For lookups and enrichment, three are common:

PurposeLikely basisKey test
Fraud screening at sign-up or before sending a passcodeLegitimate interests, Art. 6(1)(f)Balancing test; Recital 47 names fraud prevention
Choosing the channel for messages the customer asked forContract, Art. 6(1)(b), or legitimate interestsMust be necessary, not merely useful
Cleaning a list before a campaignLegitimate interests; consent for the campaign itself under e-privacy rulesReasonable expectations of the people on the list
Enriching records "in case it's useful"Hard to justifyNo specific purpose, so purpose limitation fails

Recital 47 says processing "strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest of the data controller concerned". It also says the interests of the person can override where data is processed "in circumstances where data subjects do not reasonably expect further processing". The European Data Protection Board sets out three cumulative conditions for Article 6(1)(f): a legitimate interest, necessity, and a balancing test that the person's rights don't override (EDPB, 2024).

Enrichment deserves a separate warning. If you collected a number to send order updates and later run lookups to build marketing segments, that is a new purpose. Article 6(4) asks you to assess whether it is compatible with the original one, looking at the link between purposes, the context and the person's reasonable expectations. Silent enrichment often fails that test.

What must people be told when you check their number?

It depends on where the data came from. Article 13 applies when you collect data from the person, for example when they type their number into your sign-up form. Your privacy notice should then mention that you verify numbers, why, and on which lawful basis.

Article 14 applies where personal data "have not been obtained from the data subject". Lookup results fit that description: they come from a provider, not from the person. Article 14(2)(f) asks you to say "from which source the personal data originate". Under Article 14(3), you must inform people within a reasonable period, "at the latest within one month", or at the first communication if you use the data to contact them.

Article 14(5)(b) lets a controller skip individual notices where providing them "proves impossible or would involve a disproportionate effort". In that case it must take "appropriate measures to protect the data subject's rights", "including making the information publicly available". That's the reason lookup providers publish notices for people who never dealt with them. Ours is the notice to people whose number or e-mail is checked. It covers what we hold, where it comes from, how long we keep it and how to object.

How long can you keep lookup results?

Only as long as the purpose needs. Article 5(1)(e) (storage limitation) applies to results as much as to the number. For most flows, the decision and its date are enough, for example sms_ok=true, checked 2026-09-25. The raw response can go within days.

Results also age. Numbers are ported, recycled and abandoned, so an old result can be wrong about the person who holds the number today. Keeping stale results is a retention problem and an accuracy problem (Article 5(1)(d)). On our side, real-time lookups are kept for 7 days and bulk jobs for 30 days by default. Customers can set a shorter or longer bulk retention period, up to 24 months. The trust page lists the details.

What rights do people have over lookup data?

The usual rights apply to the number and to the results: access (Article 15), rectification (Article 16), erasure (Article 17) and objection (Article 21).

Objection matters most for lookups, because most rely on legitimate interests. Under Article 21(1), once someone objects, "the controller shall no longer process the personal data unless the controller demonstrates compelling legitimate grounds" that override the person's interests, or needs the data for legal claims. For direct marketing, the right to object in Article 21(2) and (3) has no such exception.

In practice:

  • Keep a suppression list keyed on the E.164 number and check it before every lookup.
  • Tell your provider about objections that affect it.
  • People can object to checks made through MobileValidate with our opt-out form. Suppressed numbers come back as suppressed, aren't checked and aren't charged. The confirmation doesn't reveal whether we hold data about a number.

Can a lookup result decide on its own to reject someone?

Be careful. Article 22(1) gives people the right "not to be subject to a decision based solely on automated processing" that "produces legal effects" or "similarly significantly affects" them. Exceptions exist, for example where the decision is necessary for a contract, but they come with safeguards such as human review.

Blocking a passcode to a premium-rate number is unlikely to reach that threshold. Refusing someone a financial product because a lookup said "VoIP" might. Use lookups as signals, offer another route (a different channel, a manual review), and never treat unknown as a negative. We return registered / not registered / unknown with a checked_at time so that your rules can tell "no" apart from "no data".

What are the key takeaways?

  • Most phone numbers are personal data under Article 4(1) GDPR: mobiles, sole traders' numbers and employees' direct lines. A company switchboard usually isn't (Recital 14).
  • Identifiability is judged by the means reasonably likely to be used (Recital 26; Breyer, 2016). The business that holds the number can almost always identify the person.
  • Hashing and masking are pseudonymisation, not anonymisation. Hashed numbers usually remain personal data for you.
  • A lookup is processing, and its result is new personal data. It needs a purpose, a lawful basis, a retention period and transparency (Articles 5, 6, 13 and 14).
  • Honour objections with a suppression list, keep decisions rather than raw results, and don't let a lookup alone make significant decisions about people.
  • This isn't legal advice. Consult your counsel, and see our privacy checklist for the operational steps.

Sources

  1. Regulation (EU) 2016/679 (General Data Protection Regulation), Articles 4, 5, 6, 13, 14, 21, 22; Recitals 14, 26, 47 — European Union (EUR-Lex), 2016
  2. Judgment of 19 October 2016, Breyer, C-582/14, EU:C:2016:779 — Court of Justice of the European Union (EUR-Lex), 2016
  3. Judgment of 4 September 2025, EDPS v SRB, C-413/23 P — Court of Justice of the European Union (EUR-Lex), 2025
  4. Guidelines 1/2024 on processing of personal data based on Article 6(1)(f) GDPR (version 1.0) — European Data Protection Board, 2024

Frequently asked questions

Is a mobile phone number personal data under the GDPR?

In most cases, yes. Article 4(1) GDPR covers any information relating to an identified or identifiable natural person, and a mobile number usually belongs to one person and can be linked to them with reasonable effort. Treat mobile numbers as personal data unless you have a documented reason not to.

Are business phone numbers personal data?

It depends on whose number it is. Recital 14 says the GDPR does not cover the contact details of legal persons, so a company switchboard is usually outside it. A sole trader's number, or an employee's direct line or work mobile, relates to a natural person and is usually personal data.

Is a hashed phone number still personal data?

Usually, yes. Hashing is a form of pseudonymisation, and Recital 26 says pseudonymised data that can be attributed to a person with additional information should be treated as personal data. Because the set of possible numbers is small, many hashes can be reversed by trying every number.

Is the result of a phone number lookup personal data too?

Usually, yes. A result such as a line type, a carrier or whether the number has an account on a messaging app is information relating to the person who holds the number. It is new data about them, so it needs a purpose, a lawful basis, a retention period and transparency like the number itself.

Is this article legal advice?

No. It explains how the GDPR text and case law are commonly read for phone-number lookups. Your obligations depend on your purpose, your role and your country, so consult your own counsel before relying on it.

All articles

Know before you send.

Tell us about your use case. We review every request and set you up with test and live keys.