Agnes reviews a data type overview on her screen and marks which data qualifies as personal data

What counts as personal data under GDPR? A practical guide for SMBs

GDPR, Compliance, SMB

When you hear "GDPR," you probably picture a list of customer names and email addresses. That is understandable. But the official definition of "personal data" is significantly broader than that.

The gap between what people think counts as personal data and what the law actually considers personal data is exactly where most GDPR mistakes happen.

This article explains the definition in plain language and gives you a practical way to identify which data in your organisation falls under GDPR.

The official definition, and why it is broader than you expect

GDPR defines personal data in Article 4(1) as: "any information relating to an identified or identifiable natural person."

The key words are "or identifiable." You do not need to be able to directly name someone for something to count as personal data. If you hold information that allows you to identify a person, directly or indirectly, with reasonable effort, it is personal data.

That "indirect identification" clause is what surprises most SMBs.

Direct personal data: what everyone knows

Direct personal data is data that can be linked to a person without additional steps:

  • Full name
  • Email address (personal or business, if traceable to a person)
  • Phone number
  • Home address
  • Date of birth
  • National identity number
  • Passport or driving licence number
  • Photo in which a person is recognisable
  • Voice recording traceable to a person

These are the cases most businesses already recognise and have taken measures for.

Indirect personal data: the category most SMBs miss

Indirect personal data is data that does not directly lead to a person on its own but does when combined with other information you have available.

These are the cases that catch most SMBs off guard:

IP addresses. The European Court of Justice confirmed that dynamic IP addresses are personal data for organisations that have the means to identify the person behind them. For most businesses with a website, this applies. Every web server, analytics platform, and contact form that logs IP addresses is processing personal data. This is why Google Analytics required configuration changes after GDPR came into force.

Device IDs and cookie IDs. A unique identifier linked to a device or browser is personal data if it allows the behaviour of an individual to be tracked over time.

Business email addresses. john.smith@company.com is personal data. It identifies a person, not just a company.

Location data. GPS coordinates, check-in data, or travel patterns that are consistent and traceable to an individual.

HR data. Performance reviews, sick leave records (even if you only record the date without a diagnosis), salary data, appraisal notes, disciplinary files.

Job applicant data. CVs, cover letters, interview notes, reference check results. These are personal data from the moment you receive them.

Behavioural data that is traceable. Click patterns on your website, session recordings (tools like Hotjar or Clarity), customer interaction history in your CRM. If the data is linked to a profile or an ID that leads to a person, it is personal data.

Invoice data with name and address. An invoice with the name and address of the recipient contains personal data, even though it is primarily a financial document.

Special categories: extra protection required

GDPR recognises a separate category for data that is particularly sensitive. Processing this data requires not only a standard lawful basis (Article 6) but also an explicit exception from Article 9.

Special categories include:

  • Health data (medical records, sick leave reasons, medication use)
  • Racial or ethnic origin
  • Political opinions
  • Religious or philosophical beliefs
  • Genetic data
  • Biometric data for identification purposes (fingerprints, facial recognition)
  • Data concerning sexual orientation or gender identity
  • Criminal conviction data

Practical SMB examples where special categories arise: a medical practice holding patient records, an HR system recording the reason for sick leave, an access control system using fingerprint scanning, a background check provider.

When you process special categories, the threshold is higher and the documentation obligation is heavier. A DPIA is required in most cases.

Anonymous versus pseudonymous: what the difference means for you

Anonymous data falls outside GDPR. If data has been processed such that a person can no longer be identified, directly or indirectly, even with additional information, then GDPR obligations do not apply. Aggregated statistics ("our website had 12,000 visitors this month") are anonymous data.

Pseudonymous data still falls under GDPR. If you replace a name with a user ID but can still look up the link, the data is not anonymous. The data subject is still identifiable, by you. Pseudonymisation is a good security measure that GDPR actively encourages (Article 25), but it does not remove GDPR obligations.

The bar for genuine anonymisation is high. If in doubt, treat the data as personal data.

Personal data in your SaaS tools: a practical check

Go through your five most-used tools. For each one, ask:

  • Does this tool store names, email addresses, or phone numbers? If yes: personal data.
  • Does this tool log IP addresses or device IDs? If yes: personal data.
  • Does this tool contain customer interaction histories or behavioural data? Check whether that data is traceable to individuals. If yes: personal data.
  • Does this tool process HR data about employees? If yes: personal data, and possibly special categories.
  • Does this tool collect job applicant data? If yes: personal data.

If you answer "yes" to one or more of these questions, you are a data controller or processor under GDPR.

In ComplianceHive you can record per tool which personal data is processed, on what lawful basis, and for how long.

What to do once you know you're processing personal data

The first step is to document. Which tools in your organisation process personal data? Whose data? For what purpose? On what lawful basis? How long do you keep the data?

This is the foundation of a record of processing activities (RoPA), the most fundamental step in GDPR compliance. Our step-by-step guide to building a processing register will walk you through it.

The next step per processing activity is to set the retention period and build a policy to actually delete the data when that period is reached.

Now that you know what personal data is, the next step is mapping which data your organisation processes. ComplianceHive helps you document that step by step. Try free for 30 days.

This article is general information and not legal advice. Consult a qualified lawyer or privacy specialist for an assessment specific to your situation.


Start gaining control over your vendors and software today

Let ComplianceHive help you with ISO 27001, GDPR, vendor management, and more. No hassle, no spreadsheets, just clarity. Start now with a free 1-month trial. No credit card required, no hidden fees. Discover the Busy Hive plan and manage up to 25 tools and vendors in one overview.

Try 1 month for free