GDPR Glossary: Notes on Basic GDPR Terms, with Examples (Chapter 1, Section 3) — Guide to the GDPR

This chapter describes selected terms that will help to understand and apply the GDPR – Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC.

Under Article 4(1) GDPR, a data subject is:

an identified or identifiable natural person.

A data subject is an identified or identifiable natural person.

A data subject has specific rights described by the GDPR, including right to be know that, how, and what for their data are being processed by anyone else, the right to a copy of their data, right to rectify their data, right erasure, right to object and other rights.

Under Article 4(1) GDPR:

‘personal data’ means any data relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is someone who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, or an online identifier, or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.

Personal data are: (1) information (any information) concerning (2) an identified or identifiable (3) natural person.

Personal data are: (i) disclosed – anything that somebody reveals about themselves or which other sources reveal about that person (e.g., public registers); (ii) observed – anything that we observe about an individual (e.g., their behaviour, when they come home and switch on the television, their movements, whom they make cash transfers to, where and when they make cash machine withdrawals); (iii) concluded – anything we deduce about an individual and the kind of person we consider them to be, for example when we classify a person as being in an automobile accident high-risk group due to their style of driving.

At the moment, data of persons conducting business activity are subject to general protection under the GDPR.

Categories of data. The notion of ‘categories of data’ has not been defined in the GDPR. A ‘category’ is a generic notion, which could have different levels (division, family, species, genus – these are all categories). For example, ‘information’ is a higher category than ‘personal data’, and ‘personal data’ is a higher category than ‘special categories of personal data’, and ‘special categories of personal data’ is a higher category than ‘religious data’ or ‘ethnic origin data’. ‘Religious data’ may be further categorized into monotheist, polytheist, atheist, agnostic, or more specifically Christian, Muslim, Buddhist, Jewish, Hinduist, Shinto, atheist etc. Then Christian may be further divided into Catholic, Orthodox, Evangelicals, Mainline Protestants…

‘Type of data’ is an another mysterious GDPR concept.

GDPR refers to the ‘types of data’ in Article 6(3) 2 and in Article 28. Article 6(3) 2 GDPR requires statutes to specify ‘types of data’ which are processed on the legal basis laid by Union’s or Member State’s law. Article 28 GDPR concerns engaging processors (of data) by (data) controllers and states that the data processing agreement should specify ‘type of data’ entrusted to processing.

Assuming good intentions of the EU legislator, the notion “type/s of data” might have been devised to allow a little more freedom of description of, er…, types of data subject to processing based on laws or data processing agreements. In practice, the tendency is to specify as many categories of data in a law or an agreement, as technically possible, ..and adding “other types/categories of related data” (or something similar) at the end of the list.

Under Article 4(2) GDPR:

‘processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure, or destruction.

The notion of ‘processing’ consists of two elements: (i) a general definition and (ii) an open-ended list of examples of ‘processing’.

“Processing” of data consists of technical “operations” which usually serve to perform functional “activities of processing” serving a particular goal from a perspective of a data controller (e.g. accounting, marketing, sales).

Processing “operations” is an another GDPR term of significant importance. Article 4 (2) GDPR defining what is ‘processing of personal data’, explains processing operations as ‘any operation or set of operations which is performed on personal data: such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction’.

As a rule, with regard to personal data, an institution can only act in two ways – as a controller (using data for its own purposes) or a processor (processing data for a different entity).

Under Article 4(7) GDPR:

‘Controller’ means a natural person or legal person, public authority, agency, or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by EU or member state law, the controller or the specific criteria for its nomination may be provided for by EU or member state law.

A controller determines by itself (or jointly with other controllers) (i) the purposes and (ii) means of data processing. A controller can be a natural person or legal person operating in any legal form, public authorities, an agency, or other authority.

A controller may process data by themselves, it may instruct another entity (a processor) to process data on their (the controller) behalf, it may also transfer data to another controller or to other (than a controller or a processor) data recipient.

According to Article 26 (1) GDPR

Where two or more controllers jointly determine the purposes and means of processing, they shall be joint controllers

The operator ‘AND’ suggests that two or more organisations should jointly agree on BOTH the purposes of the processing AND the means of processing (e.g. the choice of technical infrastructure) to be able to recognise them as joint controllers.

However, the supervisory authorities sometimes tend to treat as joint controllership also situations where only purposes of processing are jointly decided (which makes sense) OR means of processing are jointly decided by the parties. The latter situation, where only one party decides on purposes but both agree how the data are processed seems technically identical with entrusting data processing to a data processor. Hence it makes the line between joint controllership and data processing in the meaning of Article 28 of the GDPR blurry and should be approached with caution.

According to Article 26 of the GDPR, joint controllership should be regulated by an agreement reflecting primarily the responsibilities and relationships of the joint controllers vis-à-vis the data subjects.

Joint controllership should be considered in a situation where at least two controllers jointly set purposes and means of processing. For example a group of companies may jointly control some personal data of their customers or employees (e.g. in relation to the contents of their intranet), an entity running their social media profile is considered to be a co-controller of the profile visitors and followers with an operator of a social media platform (The Court of Justice of the European Union (CJEU) in the case of the signature of C-210/16[2] decided that a Facebook fan page operator is responsible for how Facebook uses personal data of that fan page guests).

Other examples of joint controllership:

there is one CRM system in a group of companies;
real estate company sets up several unstaffed special purpose vehicle companies for specific development projects;
a consortium agreement for the implementation of a joint project;
a purchase group.

Remember, organisations may become joint controllers either when in fact they jointly decide on purposes and means of processing personal data, or when they decide to act as joint controllers. It means that joint controllership may result either from a factual situation or from a joint decision to act as joint controllers. The distinction between a factual situation and a decision sometimes becomes important, for example when one of the companies in the group of companies acts as a service centre. Then you may either decide to treat that service centre as a data processor or as a co-controller, and act accordingly.

Under Article 4(8) GDPR:

‘processor’ means a natural or legal person, public authority, agency, or other body which processes personal data on behalf of the controller.

‘Processor’ is the name given to a role which can be performed by any organisation when it is engaged to process personal data by another organisation, specifically by a (data) controller or by another (data) processor (e.g. a SaaS provider is a data processor for their clients, a PaaS provider is a processor for a SaaS provider and sub-processor for SaaS provider’s clients).

In other words, a (data) controller may subcontract data processing to another entity, called by the GDPR, a (data) processor. Also a (data) processor may further subcontract data processing to another data processor (whom we usually call a sub-processor).

Under Article 4(9) GDPR:

‘recipient’ means a natural or legal person, public authority, agency or another body to which the personal data are disclosed, whether a third party or not. However, public authorities which may receive personal data in the framework of a particular enquiry in accordance with EU or member state law shall not be regarded as recipients; the processing of those data by those public authorities shall be in compliance with the applicable data protection rules according to the purposes of the processing.

A recipient is a broad category, including other controllers (of data), (data) processors and individuals (e.g. family members of a data subject, individual members of controller’s and processor’s personnel, as well as a data subject themselves).

As the definition of a “recipient” says, public authorities that receive data in connection with proceedings in a specific case on a legal basis do not fall under the definition of a recipient. That exception stems probably from a late realisation by the EU legislator that duties imposed on data recipients by the GDPR might collide with the procedural rules governing particular official procedures.

A controller should inform data subjects about recipients or categories of recipients of their data. In case of a ‘recipient in a third country or an international organization” a data controller should provide data subjects with additional information.

According to Article 4(17) GDPR a ‘representative’

means a natural or legal person established in the Union who, designated by the controller or processor in writing pursuant to Article 27, represents the controller or processor with regard to their respective obligations under this Regulation

Article 27 of the GDPR requires non-EU controllers to designate in writing a representative in cases when GDPR applies to their activities. To comply with that obligation it is sufficient to notify about the appointment of the representative a Supervising Authority of one of the Members States where reside individuals processing data of which results in the applicability of the GDPR.

Such representative has to be authorised (mandated) to be addressed by Supervisory Authorities and data subjects regarding all related data processing and GDPR compliance issues.

A representative should also maintain a record of processing activities of a controller or processor they represent.

A lesser known fact is, that the duty to appoint a representative applies also to non-EU data processors engaged by a non-EU controller to perform processing which is subject to the GDPR. For example, if a Japanese firm instructs a Japanese marketing agency to run a marketing campaign addressed to the EU, such Japanese marketing agency should appoint its own EU representative. For another example a US SaaS platform offering their services globally should also appoint an EU representative and notify a Supervisory Authority of their choice about appointing that representative.

A data protection officer (DPO) is a formal function defined in Articles 37–39 GDPR. The GDPR in Article 37 (1) GDPR defines situations when designating a DPO is mandatory.

DPO is a ‘watchman’ who is responsible for helping the organisation to maintain data protection compliance. DPO is obligated to inform, advise and monitor compliance with the GDPR.

The DPO can be an employee or an external specialist or even an external organisation. However, in some places such as Poland and the German Land of Bavaria only an individual can be appointed as a DPO.

DPO should be able to perform their duties independently, should be protected from a conflict of interests and needs to be protected from being dismissed or penalised for performing DPO tasks.

Contrary to a common misconception the DPO is not, and cannot be responsible for the organisation’s compliance with the GDPR and, more broadly, data protection. Therefore a DPO cannot held an important managerial function in an organisation. Also, a DPO should not be treated as a main source of GDPR related legal advice, as it would create a conflict with their monitoring and audit function.

Controllers and their EU representatives are required to maintain a record of (data) processing activities (Article 30(1) GDPR). Processors and their EU representatives are required to maintain a record of categories of processing activities they carry out for controllers.

There is no direct definition of a ‘processing activity’ in the GDPR, even though this is a fundamental term from the perspective of controller’s and processor’s duties to maintain records of their data processing activities and, respectively, categories of data processing activities.

In practice, a data processing activity is a business process involving processing of personal data, such as:

Therefore, a processing activity is a larger or smaller (or longer or shorter) segment of a business process performed for a specific purpose. Businesses are free to ‘chop up’ their processes into data processing activities, provided that consistency with a specific purpose is maintained and the list of activities in the records of data processing activity is manageable.

The distinction between data processing activities and categories of data processing activities is blurred. In reality it seems both are the same, only processors do not need to include certain details of those data processing activities, that controllers are required to specify in their registers. For example processors are not required to list goals of processing, categories of data subjects and categories of their personal data, categories of recipients of data, envisaged time limits for erasure of different categories of data (where possible).

As mentioned above, Article 30 of the GDPR requires controllers (and their EU representatives) to maintain in writing records of data processing activities (RDPA), and processors to maintain records of categories of processing activities (RCPA).

Those records are a form of documenting of what an organisation “does” with personal data it possesses. They serve as a data processing map, and are a crucial element of complying with the principle of accountability (Article 5(2) GDPR). They also play an informative role and are a source of information about data processing procedures in the organisation in question for a supervisory authority.

Most of the data controllers and data processors have to maintain RDPAs. Article 30(5) GDPR theoretically relieves some entities employing less than 250 employees from that obligation. However, first, exemptions from the exemption of having an RDPA are illusive; second, it makes no sense not to have an RDPA. RDPAs are discussed further in a separate section.

In the fundamental Article 24, and in many other provisions, the GDPR relates the mere legality of processing of personal data as well as the required security measures to the risk for the rights and freedoms of data subjects resulting from processing of their data. This is the, so-called, the risk-based approach to data processing and data protection in the EU.

Recital 75 GDPR states, and it is stated in twenty-seven other places in which this wording is used, that this is about a ‘risk to the freedoms and rights of natural persons’ (data subjects). This does not refer to the risk to an organisation (e.g. of a penalty or direct damage to a business, or a risk of claims, when personal data is lost or leaked). It is a question of the harm that can be done to the data subjects. Data protection measures as well as other measures taken to comply and prove compliance with the GDPR (Article 24(1) GDPR) have to be adapted to minimise and suit the risk to the rights and freedoms of natural persons.

The risk to personal rights and freedoms may result directly from the intended processing, for example when we collect special categories data (about health, sexual preferences, religious beliefs etc) for the purpose of marketing our services, or from a comparison between legitimate interests of a (data) controller and particular interests or fundamental rights and freedoms of a data subject, and finally from a risk of a data breach – a loss of control of data by a controller or processor (hacking, fishing or another attack; unintended disclosure e.g. in a publicly available cloud resource; loss of a laptop, addressing a letter to a plainly wrong or old address of a data subject etc).

Recital 75 GDPR provides a useful list of risks related to processing of personal data:

The risk to the rights and freedoms of natural persons, of varying likelihood and severity, may result from personal data processing which could lead to physical, material or non-material damage, in particular: where the processing may give rise to discrimination, identity theft or fraud, financial loss, damage to the reputation, loss of confidentiality of personal data protected by professional secrecy, unauthorised reversal of pseudonymisation, or any other significant economic or social disadvantage; Where data subjects might be deprived of their rights and freedoms or prevented from exercising control over their personal data; where personal data are processed which reveal racial or ethnic origin, political opinions, religion or philosophical beliefs, trade union membership, and the processing of genetic data, data concerning health or data concerning sex life or criminal convictions, and offences or related security measures; where personal aspects are evaluated, in particular analysing or predicting aspects concerning performance at work, economic situation, health, personal references or interests, reliability or behaviour, location or movements, in order to create or use personal profiles; where personal data of vulnerable natural persons, in particular of children, are processed; or where processing involves a large amount of personal data and affects a large number of data subjects.

The GDPR requires controllers and processors to take into account both (i) severity of potential harmful consequences of processing or data breach, and (ii) likelihood of occurrence of such harmful consequences. Therefore, controllers and processors are required to perform and maintain appropriate documented risk analyses.

The risk of data processing should be taken into account when deciding on two main aspects of data processing:

As mentioned above, a controller and processor have to adopt measures appropriate to the risk the processing poses to the rights and freedoms of data subjects.

The GDPR requires controllers and processors to take into account:

To be able to demonstrate compliance with those requirements controllers and processors should, in practice, conduct and maintain a documented risk analysis concerning data they process, usually in the context of particular data processing activities

In certain cases GDPR requires a data controller to conduct a formal data protection impact assessment

Data protection impact assessment (DPIA) is a formalised description of planned data processing operations (or change thereof), usually constituting a data processing activity, required by Article 35 of the GDPR when it is likely that processing may result in high risk to the rights and freedoms of natural persons (data subjects).

Article 35 lists certain examples when a DPIA is required, e.g. extensive profiling leading to legal effects concerning those persons or similar effects (e.g. a decision to deny a loan); large scale of processing of special categories of data (e.g. health or political data); and monitoring of a publicly available area.

A DPIA consists of describing the categories of data, categories of data subjects, legal grounds for processing, assets used for processing, risks associated to processing (taking into account assets used for processing), inherent risks for data subjects, technical and organisational measures (TOMs) applied to mitigate those risks and residual risks after the application of TOMs.

In practice, a DPIA structure is useful for all sorts of data processing activities, not only those which we “suspect” of generating high risk for data subjects.

Under Article 4(12) GDPR:

‘personal data breach’ means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored, or otherwise processed.

A personal data breach occurs when information security is compromised, and this leads to loss of control of the data due to the data becoming corrupt or being destroyed, the data becoming inaccessible, unauthorised access being gained to the data, the data being made public, etc.

Personal data breach is in fact a violation of information security resulting in consequences (leak, unauthorised access, alteration, destruction, inaccessibility of data).

The supervising authorities often extend the scope of a notion of the personal data breach to situations where a security incident happened but there is no proof that personal data where indeed compromised. But note here that also the NIS 2 Directive adopts an effects-based definition of “incident”:

incident’ means an event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems

The Cyber Resilience Act also relies on the NIS 2 Directive’s definition of an “incident”, hence it is systemically consistent with the “effects-based” definition of the personal data breach contained in the GDPR.

The GDPR does not expressly define ‘personnel’ even though it refers to this term (Article 47(2)n GDPR).

It needs to be understood that any organisation, being it a controller, processor, supervisory authority, third party, and law enforcement institutions make use of personnel.

In practice, the definition of personnel is contained within the definition of a third party (Article 4(10) GDPR). This mentions the following persons we classify as ‘personnel’ – ‘persons who, under the direct authority of the controller or processor, are authorised to process personal data’.

Personnel of an organisation is a category of “recipients” of data. So we often mention “and their authorised personnel” when informing data subjects of the categories of recipients of their data.

Data export is a phrase used in jargon to mean the transfer of data to a third country (a country outside the EEA) or international organisation (not to be confused with data portability – the right to transfer data from a controller (provider) to a controller (provider)). This form of transfer of data to outside of the EU is subject to additional regulation, and a data subject whose data are to be moved to outside of the EEA has at least to be notified of this.

Data transfer is a transfer of data to a third country (a country outside the EEA) or an international organisation. Data export in data protection jargon means the same as data transfer. Data transfer/data export should not be confused with data portability – the right to transfer data from a controller (provider) to a controller (provider). Transfer of data outside of the EU is subject to additional requirements; for example, data subjects whose data are to be moved to outside of the EEA have at least to be notified of this. We discuss transferring data out of EU in Chapter 5 (Articles 44–50 GDPR).

The GDPR does not define ‘anonymisation’ or ‘anonymising’, but it is useful to understand what anonymisation is to distinguish it from pseudonymisation.

We use the term ‘anonymising’ to describe stripping sets of personal data (records) of such attributes (certain personal data) which allow identifying persons (data subjects) these sets of data (records) concern – permanently.

In other words, anonymisation means replacing identification data with some not meaningful values. ‘Identification data’ include usually family name, different personal identification numbers (personal ID, tax ID, social security ID, client ID, user unique identification number, numbers of other personal documents). But pending on circumstances erasing (or overwriting) of other data might be needed (car licence plate numbers, mobile phone IMEI number, etc.).

Anonymisation techniques are often used to erase (delete) personal data from databases. Instead of deleting the whole record (which you can imagine as a single row in a spreadsheet), the content of specific entries (cells) is overwritten with meaningless data (or blacked out in case of paper records). It can be done by replacing personal identification numbers with other numbers, in such a way that you are no longer able to identify persons described, but you can still conduct useful analysis on a data set.

Why not delete the whole record (row) instead? Because the integrity of a whole database may be compromised, the other records may be affected, and data in your database may become shuffled like a pack of cards (which would amount to a personal data breach). The problem is easy to imagine to anyone who tried to segregate a spreadsheet where someone merged cells before. You may also wish to use the data set for further analyses, for example in case of a patient data set to find correlations between a lifestyle and disease developments, or to create customer profiles (unrelated to individuals), or to run tests of new IT systems (although in practice it is difficult to test systems on truly anonymised data).

For data to be considered anonymised there should be no practical risk of reidentification. It means that anonymisation should be real. It sounds obvious, but in practice IT departments have a tendency to pretend anonymisation or to ‘overlook’ specific identification data (e.g., unique insurance policy number), often for purely convenience reasons.

Under Article 4(5) GDPR:

‘pseudonymisation’ means personal data processing in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person.

Pseudonymisation is replacement of identifiers (e.g., first name, surname, official individual identification number, telephone number, email address) with pseudonyms, i.e. codes, numbers, or images (and here there is a certain amount of freedom) unique to a particular individual which do not have any real connection to the person in question. In other words, this is a separation of personal data in such a way that the data revealing the identity of specific individuals is replaced with data that has no meaning (pseudonyms or usually numbers connecting a concealed identity data file with descriptions of features of the individuals in question).

Pseudonymisation is a means of data protection as well as a means of minimising access. The GDPR mentions pseudonymisation fifteen times.

Under Article 4(3) GDPR:

‘restriction of processing’ means the marking of stored personal data with the aim of limiting their processing in future.

This legal definition of restriction of processing does not tell us much, but there is its another element in Article 18(2) GDPR, which says that where processing has been restricted, personal data shall, with the exception of storage, only be processed with the data subject’s consent or for the establishment, exercise or defence of legal claims or for the protection of the rights of another natural or legal person or for reasons of important public interest of the EU or of a Member State.

So, the restriction of processing is a right of a data subject by which a data subject requests two things simultaneously: (1) preserving (storing) the data for evidence purposes in case of a further action by as data subject; (2) refraining from other processing than just holding the data for the authorities or doing what a data subject expressly agreed to.

In view of the principle of restriction of processing, a data controller may possess (store) data and perform only operations (i) consented to by the data subject and, independently, data (ii) needed for a dispute or to protect another entity’s rights or where there is an important public interest.

Restriction of processing is not automatically granted though. A data controller may reject a data subject request for restricting of processing.

A person requests a copy of a CCTV recording documenting alleged pickpocket in action. But a data controller is not sure if the footage is clear enough, and moreover there are other people’s faces. So the data controller rejects the request for a copy of data (based on rights of others) but instead advises the person that she may request the restriction of processing to preserve the recording as a piece of evidence in case the Police decides to open an investigation.

European Data Protection Board is a supra-national body composed of the head of one supervisory authority of each Member State and the European Data Protection Supervisor, or their respective representatives. EDPB may issue guidelines, helps to resolve competence conflicts between supervisory authorities and serves to align their interpretation of the GDPR.

A supervisory authority is an authority in an EU Member State (and the European Data Protection Supervisor for the EU itself) that controls compliance with the GDPR and other personal data protection laws in a particular Member State or in the case of the European Data Protection Supervisor by the EU bodies.

In most EU countries there is only one data protection supervisory body. However Germany (17), Austria (2) and Spain (4) have more than one.

#Preliminary Remarks

#3.1 Data Subject

#3.2 Personal Data

#3.3 Categories of Personal Data

#3.4 Types of Data

#3.5 Processing (of data)

#3.6 Processing Operations

Operations which constitute data processing:

#3.7 Controller (of data)

Examples of Status of a Controller:

#3.8 Joint Controllership

#3.9 Processor (of data)

#3.10 Recipient (of data)

#3.11 (EU) Representative

#3.12 Data Protection Officer

#3.13 Data Processing Activities

#3.14 Records of Processing Activities, Records of Categories of Processing Activities

#3.15 Risk (of data processing)

#3.16 Risk Analysis

#3.17 Data Protection Impact Assessment

#3.18 Personal Data Breach

#3.19 Personnel

#3.20 Data Export/Data Transfer

#3.21 Anonymisation

#3.22 Pseudonymisation

#3.23 Restriction of Processing

#3.24 European Data Protection Board

#3.25 Supervisory Authority