Is a birthday personal data under GDPR?

Yes. A birthday associated with an identifiable person is personal data under GDPR Article 4(1). It needs a lawful basis to process and is subject to the standard data subject rights (access, deletion, objection).

Is date of birth special category data under GDPR Article 9?

Date of birth itself is not in the Article 9 list (which covers race, religion, health, etc.). However, year-of-birth combined with name and other identifiers can be treated as elevated-risk in some national interpretations because it enables age inference. The cleanest posture is to not collect year-of-birth in the first place.

Do we need consent to celebrate a teammate's birthday?

Not strictly — legitimate interest under Article 6(1)(f) is the more common lawful basis for workplace birthday programs, with a documented Legitimate Interest Assessment and a clear opt-out. Consent is harder because GDPR requires consent to be "freely given," which is contested in employer-employee contexts.

Can we keep using a Google Sheet for birthdays?

Technically yes, but it's a weak privacy posture. A spreadsheet in someone's personal Drive isn't access-controlled, isn't in your RoPA, doesn't have a documented retention policy, and is fragile if the owner leaves. A centralized tool with proper controls is materially better — and the operational reliability is better too.

What about transferring birthday data to a US-based Slack bot?

EU-to-US transfers are workable post-Schrems II under the EU-US Data Privacy Framework. The transfer should be documented in your RoPA. Choose a vendor that minimizes the data sent across the border — Cake Day, for example, sends only first name and handle to the AI provider, with no year-of-birth in the system at all.

How long should we retain birthday data?

For the duration of employment plus a short administrative buffer (commonly 30 days), unless your industry has different retention rules. Document the retention period in your privacy notice and ensure your tool actually enforces it on offboarding.

GDPR and Birthdays at Work: What HR Actually Needs to Know

The short answer

If you operate in the EU or UK and run a workplace birthday program, GDPR applies to it. Specifically:

A birthday is personal data. GDPR Article 4(1) defines personal data as any information relating to an identified or identifiable person. A name + birthday clearly qualifies.
Year of birth raises the stakes. Date of birth with year enables age inference, which interacts with ADEA in the US and with several anti-discrimination provisions in EU law. In some interpretations and combinations, it crosses into Article 9 special-category territory.
Month and day only is materially safer. It still requires a lawful basis and proper controls, but the worst-case data sensitivity is much lower.

This is not legal advice — talk to your DPO or counsel. But the working pattern below is what most privacy-aware companies converge on.

What the regulations actually say

The relevant GDPR articles for a birthday program:

Article 4(1) — definition of personal data. Any info about an identifiable person. Birthday qualifies.
Article 5(1)(c) — data minimization. Personal data must be "adequate, relevant and limited to what is necessary." This is the article you cite when you want to defend collecting month/day only.
Article 6 — lawful basis. You need one. Legitimate interest under 6(1)(f) is usually the right basis for a birthday program (running team rituals is a legitimate operational interest, balanced by a clear opt-out).
Article 9 — special category data. Includes data revealing racial origin, political opinions, religious beliefs, health, etc. Age itself is not listed as special category, but year-of-birth combined with other identifiers is sometimes treated as elevated-risk under national interpretations.
Article 13/14 — transparency. You must tell teammates what you're collecting, why, and how to opt out.
Article 17 — right to erasure. A teammate must be able to remove their data with reasonable effort.
Article 25 — data protection by design. The design of the system must minimize data collection by default.

For UK organizations, the UK GDPR is functionally identical on these points. The ICO's guidance on workplace data is the most accessible English-language reference.

Why year of birth specifically is the issue

The big risk in workplace birthday data isn't the birthday itself — it's the year.

Year of birth enables age inference, and age is:

A protected characteristic under the Equality Act 2010 (UK) and parallel EU directives.
A protected characteristic under the Age Discrimination in Employment Act (ADEA) in the US, for teammates 40+.
One of the four core fields used in identity theft (with name, address, government ID).
A field that, once collected, you must defend in any breach, audit, or DSAR (data subject access request).

A common pattern: a company collects year of birth because the original tool's schema asked for it. That data sits in a database. A teammate over 40 is later involved in a redundancy. They file a discrimination claim. The opposing counsel asks: "Did the company hold age data on this employee?" The answer is yes, and now the company is defending why they had it, who could see it, and what they did with it.

You can avoid all of that by simply not collecting it.

What "data minimization" looks like for a birthday program

GDPR Article 5(1)(c) is unusually direct: collect only what you need. For a birthday program, the actual operational data needed is:

Data	Need?	Why
First name	Yes	Used in shoutout copy.
Slack handle / user ID	Yes	Used to tag in the post.
Birth month	Yes	Determines when to post.
Birth day	Yes	Determines when to post.
Birth year	No	Not required for posting. Materially raises risk.
Country / region	No	Unless your program has regional logic, which most don't.
Religion / cultural notes	No	Unless explicitly volunteered for an opt-in cultural calendar.

The honest test: can your program work with just month and day? Almost always, yes. We built Cake Day's database with no year-of-birth column at all — not "we don't display it," literally no column. That's data minimization in practice.

The lawful basis question

You need a lawful basis under Article 6 to process birthday data. The realistic options for a workplace birthday program:

Consent (Article 6(1)(a)). You ask each teammate to consent to having their birthday celebrated. Pros: clearest framing. Cons: GDPR requires consent to be "freely given," and there's a long-running debate about whether employee consent can ever be truly free given the power imbalance. Most DPOs avoid this basis for routine workplace processing.

Legitimate interest (Article 6(1)(f)). You assert that running team rituals is a legitimate operational interest, you've balanced it against the teammate's rights, and you've provided a clear opt-out. Pros: doesn't have the "freely given" problem. Cons: requires a documented Legitimate Interest Assessment (LIA).

For most workplace birthday programs, legitimate interest is the right basis. The LIA is short — three sentences confirming the interest, the necessity (would the program work without this data? no), and the balancing test (is this proportionate? yes, with opt-out).

The teammate-facing rights

Whatever basis you choose, teammates have to be able to:

Know you're processing their data. A line in the employee handbook or a Slack post when the program is introduced. "Cake Day stores your birth month and day so we can celebrate you on the day. You can remove your data at any time with /cakeday optout."
Access their data. A DSAR-friendly export or "show me what you have" command.
Delete their data. One-command opt-out, no conversation, no manager approval.
Object to processing. Same as opt-out — a single action they can take unilaterally.

A program that meets these is in good shape. A program where opt-out requires emailing HR and waiting 5 days is not.

Cross-border transfer

If your Slack workspace is hosted in the US (most are) and the bot's backend is also US-hosted, you have an EU-to-US transfer. This is workable post-Schrems II under the EU-US Data Privacy Framework, but it should be documented in your record of processing activities (RoPA).

For Cake Day specifically: data is processed in US-region infrastructure (Supabase Postgres, Fly.io for the bot), with encryption at rest for sensitive tokens. The minimal data sent to AI providers is a first name and a handle — no year of birth, no broader PII.

What a defensible birthday program looks like

If you need to write one paragraph for a privacy review, this is the working template:

The team runs a birthday and work-anniversary recognition program in Slack. The system stores each teammate's first name, Slack handle, birth month, birth day, and start date. Year of birth is not collected. The lawful basis is legitimate interest under GDPR Article 6(1)(f); a Legitimate Interest Assessment is on file. Teammates can opt out at any time using /cakeday optout, which removes their data immediately. Data is processed in [region], encrypted at rest, and retained for the duration of employment plus 30 days. The full data flow is documented in the RoPA.

That paragraph passes most internal privacy reviews on the first read.

What an undefensible program looks like

In contrast, the things that fail review:

A spreadsheet with full DOB (year included) in someone's personal Drive.
A birthday tool that stores year-of-birth and offers no documented retention policy.
A program that requires emailing HR to opt out, with no acknowledgment of GDPR rights.
A program with no documented lawful basis, no LIA, no transparency notice.
An HRIS sync that pulls full DOB into a third-party tool without stripping the year.

If any of these describe your current state, the fix is straightforward: switch to a tool with proper data minimization, document the basis, and announce the program with a transparency notice.