The single line that changes the privacy posture
Most birthday tools ask for a teammate's full date of birth. Cake Day asks for two fields: month and day.
That difference looks small. It isn't. Here's why.
What year of birth actually is
Year of birth uniquely identifies someone's age, which is:
- A protected characteristic under U.S. ADEA (Age Discrimination in Employment Act) for employees over 40.
- A special category of personal data under GDPR Article 9 when combined with other identifying information.
- One of the four core fields used in identity theft (along with name, SSN, and address).
- A field that, once collected, must be defended in any data breach, audit, or compliance review.
A birthday automation needs to know it's August 14th today. It does not need to know what year someone was born. The whole apparatus runs perfectly on month + day.
What "data minimization" actually means
Data minimization is a core principle of every modern privacy framework — GDPR, CCPA, HIPAA, ISO 27001. The principle is simple: collect only the data you need to provide the service.
In practice, almost no software actually follows this. Form fields proliferate. Optional fields become required. Old fields hang around long after their use case disappears. And every one of those fields becomes a liability the moment something goes wrong.
Cake Day's database literally has no column for year of birth. It's not "we don't display it" or "we don't expose it via the API" — the column doesn't exist. There is nothing to leak in a breach. Nothing to defend in an audit. Nothing to ask your security team about.
Why other tools collect it
A few real reasons:
- Habit. Most birthday tools were built before privacy frameworks were taken seriously. The data model includes year of birth because that's what the original schema looked like.
- Milestone messages. Some tools want to say "Happy 30th!" or "Happy 50th!" — that requires year of birth. Cake Day handles milestone framing differently: admins can configure "milestone year" messages without storing the year on every teammate.
- HRIS sync. If a tool syncs from an HRIS that includes year of birth, the easiest engineering path is to store everything. A small amount of extra work strips the year before storage; not every tool does it.
None of these are good reasons in 2026.
What this means for your team
If you're picking a birthday tool, ask the question explicitly: "Do you store year of birth?"
If yes, you're inheriting:
- Compliance exposure if you operate in the EU (GDPR Article 9).
- ADEA exposure if any of your teammates are over 40.
- Breach notification scope that includes age data.
- A column you have to defend forever.
If no, you avoid all of it. The service works just as well — birthdays still post on the right day.
What Cake Day stores instead
The actual fields Cake Day stores per teammate:
- First name (used in shoutout copy)
- Slack handle (used to tag in the post)
- Birthday month + day (just the two integers — never year)
- Start date (full date — needed for anniversary year math, but stored only for active teammates)
- Opt-out flag (single boolean)
That's it. No year of birth, no age, no inferred age, no age bucket.
Want to verify?
Read our privacy policy — it includes the database schema in plain English.
Read our security page — it covers encryption, retention, and breach notification.
Read the open-source schema — for the parts that are public, you can see the column names directly.