Personal data / PII

Two traditions, one idea. 'PII' is the older American framing and it has no single fixed meaning: what counts shifts between statutes, sector rules, and standards like NIST SP 800-122, which is why two US lawyers can disagree about the same column. People often shorthand it as name, government ID, card number, account credentials, but that list is a habit rather than a definition. GDPR's 'personal data' is wider and more stable: any information relating to an identified or identifiable person, directly or indirectly, including data that lets you single someone out without ever learning their name. That sweep pulls in IP addresses, advertising IDs, cookie IDs, device fingerprints, and the user_id you pass to analytics. If you build for the EU, assume the wide definition and stop arguing.

A second tier sits on top: special categories under GDPR (health, biometrics, genetics, race, religion, political opinions, union membership, sex life or orientation) and sensitive personal information under California law (precise geolocation, government IDs, account logins, contents of messages). These carry extra duties, and they arrive in ordinary products more often than people expect: a fitness app storing weight, a dating app storing preferences, a support form where someone types their diagnosis into a free-text box.

Gotcha: identifiability is contextual and combinational. A hashed email is still personal data, because a hash is a pseudonym you can join back to a person. Postcode plus birth date plus gender can carry substantial re-identification risk, depending on the dataset and the population you are drawing from. And the awkward truth for engineers: personal data ends up in places nobody decided to put it, like Sentry breadcrumbs, request logs, warehouse tables, and a CSV in someone's downloads folder.