Personal Data: Definition, Categories, and Legal Obligations under the GDPR and the Federal Data Protection Act (BDSG)

Art. 4(1) GDPR defines personal data as all information relating to an identified or identifiable natural person. The definition is deliberately broad: names and email addresses fall within its scope, as do IP addresses, cookie IDs, biometric characteristics, and location data. For companies that process data, this gives rise to a wide range of obligations covering information duties, legal basis requirements, technical and organisational measures, and documentation obligations.

This article sets out the fundamental legal structure: which data qualifies as personal, which categories must be treated with particular sensitivity, which legal bases for processing are available, and what the obligations mean in practice for the appointment of a data protection officer. The focus is on practical implementation for German companies under the GDPR and the Federal Data Protection Act (BDSG).

Art. 4(1) GDPR defines personal data as all information relating to an identified or identifiable natural person. A person is identifiable when they can be identified directly or indirectly — in particular by reference to characteristics such as a name, an identification number, location data, an online identifier, or factors specific to the physical, physiological, genetic, mental, economic, cultural, or social identity of that person.

The European Data Protection Board (EDPB) and the Court of Justice of the European Union (CJEU) have interpreted this definition broadly in several decisions. IP addresses qualify as personal data when the controller has the legal means to identify the user (CJEU, C-582/14, Breyer). Cookie IDs, device identifiers, pseudonyms, and combinations of data that appear neutral may constitute personal data if attribution to a person is possible.

Data is not personal if it has been fully anonymised in a manner that makes re-identification impossible — a high threshold that is rarely met in practice without specialised techniques. Pseudonymisation under Art. 4(5) GDPR reduces the risk but still constitutes processing of personal data, because re-identification remains possible using the mapping key.

When in doubt, companies should assume that a personal reference exists. This is the lower-risk position and is consistent with the interpretive practice of German data protection authorities (the DSK — Conference of Independent Federal and State Data Protection Supervisory Authorities).

Art. 9 GDPR identifies eight categories of personal data whose processing is in principle prohibited unless an explicit exception ground applies. These categories are: health data, genetic data, biometric data for the purpose of uniquely identifying a person, data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, and data concerning sex life or sexual orientation.

Practically relevant for companies are in particular health data (sickness absence notifications, occupational reintegration management proceedings, occupational health records), biometric data (fingerprint scanners for access control, facial recognition), and genetic data (assessments conducted by professional trade associations). Every processing activity involving these categories requires an explicit legal basis from Art. 9(2) GDPR — for example, explicit consent (para. 2(a)), processing for purposes of employment law obligations (para. 2(b)), or processing for the purposes of occupational medicine (para. 2(h)).

For German companies, Section 26 of the Federal Data Protection Act (BDSG) additionally applies to the processing of data in the employment context. Health data of employees generated in the course of occupational reintegration management or within the company physician function is subject to heightened confidentiality and may not be disclosed to other parts of the organisation without a specific legal basis.

Every processing activity involving personal data requires a legal basis under Art. 6(1) GDPR. The six available legal bases are: consent (a), performance of a contract (b), compliance with a legal obligation (c), protection of vital interests (d), performance of a task carried out in the public interest (e), and the legitimate interests of the controller (f). In day-to-day business practice, the most relevant bases are performance of a contract, compliance with a legal obligation, and legitimate interests.

Consent under Art. 6(1)(a) GDPR sounds straightforward but is demanding in practice: it must be freely given, informed, specific, and unambiguous. In the employment context, freedom of choice is structurally questionable, which is why Section 26 of the Federal Data Protection Act (BDSG) and supervisory authorities set narrow limits here. Processing for marketing purposes is often based on legitimate interests under Art. 6(1)(f) GDPR — with a corresponding balancing-of-interests obligation that must be documented.

The chosen legal basis must be documented in the record of processing activities under Art. 30 GDPR. If a different basis is subsequently claimed, this is in principle impermissible under Recital 40 GDPR. The clock starts from the point of knowledge: the obligation to document the legal basis does not begin at the next audit — it begins with the first processing activity.

Art. 30 GDPR obliges controllers to maintain a record of processing activities (RoPA). Exempt are companies with fewer than 250 employees, provided that the processing does not pose a high risk to data subjects' rights, is not carried out on a regular basis, and does not involve special categories under Art. 9 GDPR. In practice, most companies of any significant size do not satisfy these cumulative conditions — the RoPA is effectively mandatory.

The record of processing activities must contain, for each processing activity: the name and contact details of the controller, the purposes of the processing, the categories of data subjects and data categories, the recipients or categories of recipients, transfers to third countries with applicable safeguards, retention periods, and a general description of the technical and organisational security measures.

The RoPA must be made available to the supervisory authority upon request. A missing or incomplete record of processing activities constitutes a standalone data protection violation under Art. 83(4) GDPR, with a fine of up to €10 million or 2% of total worldwide annual turnover. The data protection officer is frequently responsible for, or has a coordinating role in, the creation and maintenance of the RoPA.

The GDPR grants data subjects extensive rights to which companies must respond within defined time limits. Art. 12 GDPR requires that information is provided in a concise, transparent, intelligible, and easily accessible form — without undue delay and at the latest within one month of receipt of the request.

An overview of the most important data subject rights:

• Right of access (Art. 15 GDPR): Data subjects have the right to obtain information about the processing activities that concern them, including the purpose, categories, recipients, and retention period.
• Right to rectification (Art. 16 GDPR): Inaccurate data must be corrected without undue delay.
• Right to erasure (Art. 17 GDPR): Under certain conditions — such as the disappearance of the purpose or withdrawal of consent — data must be erased.
• Right to restriction of processing (Art. 18 GDPR): Under certain circumstances, processing may be restricted to mere storage.
• Right to object (Art. 21 GDPR): Where processing is based on legitimate interests, data subjects may object.

Companies should establish a structured workflow for handling data subject requests that documents receipt, processing, and response. Evidence of timely handling must form part of the audit trail.

Art. 33 GDPR obliges controllers to notify a personal data breach to the supervisory authority within 72 hours of becoming aware of it — unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The time limit runs from the point of awareness, not from the completion of the root-cause analysis.

The notification must contain at least: a description of the nature of the breach, the categories and approximate number of affected data subjects and data records, the likely consequences of the breach, and the measures taken or proposed to address it.

Art. 34 GDPR adds: where the breach is likely to result in a high risk to data subjects, direct notification of the affected individuals is additionally required. The boundary between notifiable and non-notifiable breaches must be assessed on a case-by-case basis. Supervisory authorities expect companies to document this assessment — even when the conclusion is that no notification is required.

An internal personal data breach register documenting each incident with the date, description, risk assessment, and measures taken is mandatory under Art. 33(5) GDPR. This record is regularly the first document requested by authorities during an inspection.

Art. 32 GDPR obliges controllers to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. Art. 25 GDPR supplements this with the principle of data protection by design and by default — known as Privacy by Design and Privacy by Default.

Specific technical and organisational measures (TOMs) cited as examples in Art. 32 GDPR include: pseudonymisation and encryption of personal data; ensuring the ongoing confidentiality, integrity, availability, and resilience of processing systems; the ability to restore availability and access to personal data in a timely manner following a physical or technical incident; and a process for regularly testing, assessing, and evaluating the effectiveness of the measures.

The choice of measures must be aligned with the risk — not with a uniform minimum standard. A hospital processing health data at high risk requires stricter measures than a retailer that stores only delivery addresses. The TOMs must be documented, reviewed regularly, and adjusted whenever the processing changes.

In practice, a TOM document that explicitly references the processing activities in the record of processing activities proves effective — so that, in the event of an audit, it is immediately clear which protective measures are assigned to which processing activity.

Art. 37 GDPR and Section 38 of the Federal Data Protection Act (BDSG) require companies to appoint a data protection officer (DPO) when at least one of the following conditions is met: the company regularly employs at least 20 persons engaged in the automated processing of personal data (Section 38(1) BDSG); or the core activities of the company consist of processing operations which, by virtue of their nature, scope, or purposes, require regular and systematic monitoring of data subjects on a large scale (Art. 37(1)(b) GDPR); or the core activities consist of large-scale processing of special categories of data under Art. 9 GDPR or personal data relating to criminal convictions and offences (Art. 37(1)(c) GDPR).

The DPO must possess expert knowledge of data protection law and practice. They may be appointed internally or engaged as an external service provider. The appointment must be made in writing and communicated to the supervisory authority (Art. 37(7) GDPR). Appointment instrument — signed, filed, demonstrable — this principle applies here just as it does to all other officer roles.

The DPO has a protected status under Art. 38 GDPR: they may not be dismissed or penalised for the performance of their duties. Conflicts of interest — for example, where the DPO also serves as head of IT — are impermissible under Art. 38(6) GDPR. It is therefore important to examine role compatibility before making the appointment.

Personal data is not one topic among many — it is the cross-cutting theme of the entire organisation. Every department processes data: HR (personnel files, payroll), sales (CRM, customer data), IT (log data, user accounts), procurement (supplier contacts). This means: data protection obligations are not a project that is completed once. They are an ongoing operating system.

This is precisely where the structural difference lies between a data protection consultant who delivers a PDF once a year and a data protection officer who is actively working in a workspace every day: new processing activities must be added to the RoPA. Personal data breaches must be reported within 72 hours. Data subject requests must be answered within one month. Training records must be on file.

CIVAC is a compliance platform and Officer-as-a-Service solution. License the workspace for your internal data protection officer or appoint our officers. In either case, 37 audit-ready templates are available, along with a structured personal data breach register, AI assistance with source citations and confidence scores, and a direct reporting line to senior management.

Others manage compliance like a filing cabinet. We manage it like software.

Turn reading into action: write to info@civac.de or use the contact form at civac.de.