EMZETT.Sensitive Data
In short: A special category of personal data (Art. 9 GDPR) whose processing is fundamentally prohibited, unless an explicit exception applies (e.g. explicit consent).
In more detail: This includes, among others, health data, genetic and biometric data, data on racial/ethnic origin, political opinion, religious belief, trade union membership, as well as data on sex life or sexual orientation. Because of the higher potential for misuse (discrimination, blackmail), stricter requirements apply to this data regarding legal basis, security and storage than for “normal” personal data.
In Depth
Art. 9 GDPR lists the protected categories exhaustively — not every sensitive piece of information automatically falls under it, only these explicitly named ones:
- Racial and ethnic origin
- Political opinions
- Religious/philosophical beliefs
- Trade union membership
- Genetic data
- Biometric data (for unique identification, e.g. fingerprint)
- Health data
- Data on sex life/sexual orientation
The basic principle is a PROCESSING BAN with a reservation of permission — unlike “normal” personal data, where a legal basis permits processing, processing sensitive data is fundamentally prohibited from the outset and only permitted under narrow, explicitly listed exceptions (Art. 9(2) GDPR): explicit consent, processing by an employer within the scope of employment law, protection of vital interests, or processing by non-profit organisations for their own members.
In practice, for software projects this means: before any field is collected that could fall into one of these categories (e.g. a “gender” field connected to sexual orientation, or a health questionnaire), one of these narrow exceptions must concretely apply and be documented — “might be useful later” is nowhere near enough, and when in doubt it’s safer not to collect the field at all.
Why exactly these categories?
The selection of special categories has historical reasons: they typically cover characteristics that can lead to serious discrimination if misused and that a person often can’t or won’t change (origin, sexual orientation), or whose disclosure affects particularly sensitive areas of life (health, religion, political conviction). A leaked health data set can, for example, lead to discrimination in insurance or job applications; leaked political or religious data can even be existentially threatening in certain countries. The GDPR responds to this elevated potential for harm with considerably stricter formal hurdles than for ordinary personal data.
Practical pitfalls when collecting data
In software development, violations often arise unintentionally, not out of bad intent: a free-text field (“other notes”) can lead to users entering health information unprompted, without the system having been designed for that — nevertheless, the same strict requirements then apply as soon as such data is actually stored. Even seemingly harmless data points can indirectly reveal sensitive categories (e.g. a diet app that implicitly allows conclusions about an eating disorder, or a name strongly associated with a particular religion) — the GDPR assessment doesn’t just depend on the literal category of a field, but also on what conclusions are realistically possible in practice from the data collected.
Technical safeguards in practice
For sensitive data, the usual standard security measures are often not enough — the legislator expects “appropriate” technical and organisational measures proportionate to the higher risk here. In practice this often means: encrypting this data both at rest and in transit, a particularly restrictive permission concept (only a few, named individuals may access it), complete logging of every access via an audit log, and often storing this sensitive data separately from the rest of the “normal” personal data, so that a data leak affecting the normal data doesn’t automatically expose the especially sensitive categories too.
See also: Personal data, GDPR