![](bg2.png)
plete introduction to data protection and GDPR, but
focus on those aspects that are more or less directly
relevant for software development. Other important
topics such as the nomination and role of the data pro-
tection officer or the role of the supervisory bodies
will not be covered here. Also, the current paper does
not address the implications of data protection on the
software processes. This topic was for example dis-
cussed in (Kneuper, 2019).
2 TERMINOLOGY AND BASIC
CONCEPTS
2.1 Data Protection
Before starting with the identification of require-
ments, we first need to define the main terminology
used. Since the goal of data protection is the pro-
tection of individuals, data protection only refers to
personal data, defined as “any information relating
to an identified or identifiable natural person (‘data
subject’)” (Art. 4(1) GDPR). (In other contexts, for
example ISO/IEC 29100:2011, the name “personally
identifying information” (PII) is used to describe the
same concept.) Therefore, when talking about “data”
in the following, this refers to personal data.
However, the exact interpretation of this term
varies with the applicable legislation. In the case of
GDPR, personal data includes data where the refer-
ence to a particular person may not be immediately
visible, as for example an IP address.
In contrast to personal data, anonymous data are
defined as data that do not refer to identifiable in-
dividuals, and therefore do not count as personal
data. Anonymous data need to be distinguished from
pseudonymous data which do refer to identifiable in-
dividuals but where this identification needs addi-
tional information which is stored separately and pro-
tected. Pseudonyms may therefore be used as a form
of protecting personal data.
In times of big data and data analysis, it is im-
portant to take into account that there are many cases
where seemingly anonymous data turn out to not be
anonymous at all, for example because they can be
related (joined) to some other data set via common
(pseudo-)identifiers or keys.
A special case of personal data are the special cat-
egories of personal data which need particular protec-
tion, as defined in Art. 9 GDPR. These include “per-
sonal data revealing racial or ethnic origin, political
opinions, religious or philosophical beliefs, or trade
union membership, and [. . . ] genetic data, biometric
data for the purpose of uniquely identifying a natu-
ral person, data concerning health or data concern-
ing a natural person’s sex life or sexual orientation”
(Art. 9(1) GDPR).
Following GDPR, this paper will count as “pro-
cessing” any form of handling data, including (but not
limited to) the collection, storage, reading and editing
of data as well as their transfer to other systems or or-
ganisations. A wording like “collecting and process-
ing of data” will occasionally be used to emphasise
the collection of data but keeping in mind that collec-
tion is actually part of processing.
Roles Involved. In GDPR and data protection in gen-
eral, one usually distinguishes three main roles:
• The data subject is the (natural) person
1
whose
data are processed and who needs adequate pro-
tection. This may include (individual) customers,
employees, visitors to a company website, and
many other individuals. In other frameworks, for
example in ISO/IEC 29100:2011, this role is also
called the “PII principal”.
• The controller is the entity that “determines the
purposes and means of the processing of personal
data” (Art. 4 (7) GDPR) within an organisation,
and therefore is fully responsible for this process-
ing. The controller may either perform the pro-
cessing itself, or subcontract it to a separate pro-
cessor.
• The processor is the entity that performs the ac-
tual processing of data, on behalf of and follow-
ing the rules set by the controller. If processing
is performed by the controller itself, there is no
processor. If a processor exists, GDPR requires a
contract between the controller and the processor
to ensure that the controller does actually control
the processing, and the processor follows the rules
set by the controller.
A fourth role, which is not described in GDPR but
important in the current context, is the software pro-
ducer, which may overlap with one of the roles men-
tioned or be a completely different entity.
2.2 Requirements
In the following, three different groups of require-
ments will be distinguished following IREB (Inter-
national Requirements Engineering Board (IREB),
2017; Pohl and Rupp, 2015): functional requirements
(marked with identifiers F-n) define the functions to
1
In GDPR, like in most legislations, data protection only
applies to natural persons. However, in some countries such
as Switzerland, data protection also applies to so-called le-
gal persons such as companies.
ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy
258