Translating Data Protection into Software Requirements

Ralf Kneuper

IUBH University of Applied Sciences—Distance Learning, Kaiserplatz 1, 83435 Bad Reichenhall, Germany

Keywords:

Data Protection, Privacy, GDPR, Software Requirements.

Abstract:

With the growth of data processing and digitalisation in many environments, data protection is also growing

more and more important. This is for example reﬂected by the General Data Protection Regulation (GDPR)

which came into effect in May 2018 and deﬁnes what organisations need to do to protect individuals and

their personal data. This paper provides a summary of the main data protection concepts, using GDPR as

an example, and from these derives the resulting software requirements that apply to software systems which

process private data within the European Union (and to some extent beyond). This way, the paper supports

software developers as well as requirements analysts in their task of identifying and deﬁning the data protection

requirements, even though they will have to be adapted and additional detail provided for any speciﬁc case.

1 INTRODUCTION

Data protection, i.e. the protection of individuals

against inadequate and unwanted use of their personal

data, is growing increasingly important, and needs to

be taken into account in software development where

many decisions are taken about how (personal) data

are processed. In the European Union, the expecta-

tions about data protection are mostly deﬁned in the

General Data Protection Regulation (GDPR), which

became applicable law in May 2018. The main goal

of this regulation is to deﬁne and ensure a largely uni-

form level of protection across the European Union.

Similar laws and regulations apply in many other

countries.

The GDPR contains a set of demands on organisa-

tions and other entities that process any form of per-

sonal data, leading to organisational as well as tech-

nical measures that need to be taken. Many of these

demands lead to requirements on any software used to

process personal information. However, GDPR does

not express these demands as software requirements.

Instead, the software requirements need to be derived

from the general demands on the handling of personal

data, which can be a challenging task for software de-

velopers without relevant legal training.

Therefore, the goal of the current paper is to iden-

tify the requirements resulting from GDPR (r similar

laws and regulations) that apply to software develop-

ment, and to express them as software requirements.

https://orcid.org/0000-0003-3225-5895

These software requirements are to be expressed as

speciﬁc as possible, accepting that this will only be

possible to a limited extent since they apply to very

different software systems, with very different per-

sonal data processed.

Note that the requirements described here refer to

the resulting product and therefore are independent of

the life cycle model and the general approach (plan-

driven, agile or hybrid) used.

Although the GDPR is used in this paper as the

reference model for data protection, many of the de-

mands as well as the resulting software requirements

are not speciﬁc to GDPR but can be found in a similar

form in most other data protection laws.

To better explain the meaning of the software re-

quirements identiﬁed and provide some ideas about

their implementation, the example of an online shop

will be used throughout this paper.

Structure of Paper. This paper is structured as fol-

lows: after the current introduction, Sect. 2 intro-

duces the terminology and main concepts used. Next,

Sect. 3 provides an overview of the main principles of

data protection as deﬁned by GDPR, and how these

principles can be translated into software require-

ments. A brief summary of the rights of the data sub-

jects is given in Sect. 4. Some additional concepts of

data protection and GDPR relevant in this context are

discussed in Sect. 5. Finally, Sect.6 gives an overview

of the validation performed on the results, and Sect. 7

summarises the main conclusions of this work.

In this paper, we will not even try to give a com-

Kneuper, R.

Translating Data Protection into Software Requirements.

DOI: 10.5220/0008873902570264

In Proceedings of the 6th International Conference on Information Systems Security and Privacy (ICISSP 2020), pages 257-264

ISBN: 978-989-758-399-5; ISSN: 2184-4356

257

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 ofﬁcer 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 identiﬁcation of require-

ments, we ﬁrst need to deﬁne the main terminology

used. Since the goal of data protection is the pro-

tection of individuals, data protection only refers to

personal data, deﬁned as “any information relating

to an identiﬁed or identiﬁable 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

deﬁned as data that do not refer to identiﬁable in-

dividuals, and therefore do not count as personal

data. Anonymous data need to be distinguished from

pseudonymous data which do refer to identiﬁable in-

dividuals but where this identiﬁcation 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-)identiﬁers or keys.

A special case of personal data are the special cat-

egories of personal data which need particular protec-

tion, as deﬁned 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

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 identiﬁers F-n) deﬁne the functions to

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

be provided by the system under development. Qual-

ity requirements (identiﬁers Q-n), also known as non-

functional requirements, describe the required qual-

ity properties of the system, such as performance or

usability. Constraints (identiﬁers C-n) deﬁne require-

ments on the environment within which the system is

to be developed rather than the system itself, for ex-

ample the use of a certain software process life cycle

model or certain documentation to be created. Some

constraints do not apply to software and the devel-

opment organisation at all but to the controller, for

example deﬁning the purpose of the processing per-

formed. Nevertheless, the development organisation

should in most cases be involved, either because they

need information such as the purpose as input, or be-

cause they need to support the controller.

To support precise formulation of the functional

requirements, they follow the template described by

(Pohl and Rupp, 2015), which in a simple variant

states “The system shall/should/– provide <actor>

with the ability to/be able to <process verb>”. How-

ever, following this template is not always possible,

for example when the requirement describes what

may not happen.

Note the difference between requirements ex-

pressed using “shall” and “should”. If requirements

need to be satisﬁed in order to conform to GDPR,

“shall” is used. If requirements are considered very

helpful but there are alternative ways to conform to

GDPR, “should” is used.

3 DATA PROTECTION

PRINCIPLES

This section discusses the basic principles of data pro-

tection as deﬁned in Art. 5 GDPR, together with the

resulting software requirements.

3.1 Lawfulness, Fairness and

Transparency

The principles of lawfulness, fairness and transparen-

cy are deﬁned in Art. 5(1)a GDPR. The principle of

lawfulness starts from the rule that processing of per-

sonal data is prohibited unless there is an explicitly

deﬁned legal basis that allows it. In Art. 6(1), GDPR

deﬁnes a list of six conditions which may form such

a legal basis. In practice, the most relevant of these

lawfulness conditions are a) consent by the data sub-

ject, b) processing for the performance of a contract

to which the data subject is party, and f) the legitimate

interest of the controller or a third party, where this

interest must be balanced against the interests of the

data subjects. Note that within any one system, dif-

ferent types of processing of the same data may take

place in parallel but with different legal bases. For ex-

ample, performing a contract may form a legal basis

for processing the address of a customer, while using

the same address for marketing purposes may require

the consent of the customer. This leads to the follow-

ing software requirement:

Requirement (C-1: Identify Legal Basis). Before

performing any processing of personal data, the rel-

evant legal basis according to Art. 6 GDPR shall be

identiﬁed and documented.

In general, the appropriate place for this documen-

tation will be the records of processing activities as

introduced in Sect. 5.1 below.

When processing data on the basis of consent, the

following properties of valid consent must be taken

into account: consent must be given freely, implying

that data subjects that do not consent may not be put at

a disadvantage, for example by not giving them access

to information on a website where this consent is not

factually necessary.

Since genuine consent is given freely, it must also

be possible to change one’s mind and withdraw con-

sent (at least for the future). Furthermore, the consent

given must be speciﬁc, referring to a speciﬁc kind of

processing and purpose. It must be informed, since

data subjects need to know and understand what their

consent infers. Consent must be unambiguous, which

implies for example that users must actively select a

consent box, while a pre-ticked box is not sufﬁcient.

Consent must also be collected in adequate granular-

ity, for example allowing customers to consent to the

use of their address for sending an annual catalogue

but not a weekly newsletter.

These demands on consent lead to the following

software requirements:

Requirement (F-1 Freely given Consent). The sys-

tem shall provide users with access to data and func-

tionality even if they did not provide consent, unless

this consent is factually necessary.

An example of factually necessary consent re-

gards the storage of user preferences for a system. If

users do not consent to this storage, then of course

they will have to set relevant preferences from scratch

every time they use the system.

Requirement (F-2 Collecting Consent). If the pro-

cessing of personal data is based on consent, the sys-

tem shall collect consent before the start of process-

ing. Before collecting consent, the system shall inform

data subjects about the purpose of the processing and

the implications of giving or refusing consent. The

Translating Data Protection into Software Requirements

259

system shall collect consent on an adequate level of

granularity. The system shall only collect consent that

is given actively and unambigously.

Requirement (F-3 Consent for Children). If consent

is to be given for a child and refers to an “offer of

information society services directly to a child”, the

system shall ensure that consent is given by the holder

of parental responsibility. (Art. 8 GDPR)

Note that the exact deﬁnition of “child” varies be-

tween legislations, even within the EU.

Requirement (F-4 Withdrawal of Consent). The sys-

tem shall provide the data subject with the ability to

withdraw consent previously given, and to give con-

sent previously refused.

Requirement (F-5 Traceability of Consent). The sys-

tem shall provide the controller with the ability to

trace consent given, refused or withdrawn, including

information about when and in what form this was

done.

Requirement (F-6 Storage of Consent). The system

should provide the data subject with the ability to

store consent given or refused beyond the individual

session.

The following requirement seems obvious, but

can become very complex, particular if consent—as

required—is collected in a granular form, and then is

partly given, partly refused, and maybe even changed

over time.

Requirement (F-7 Compliance to Consent). The sys-

tem shall comply to the consent given or refused in its

functionality, always based on the current status of

consent.

Coming back to the example of an online shop,

consent may for example be collected for sending of

marketing material such as special offers. Any system

function for sending marketing material, for example

in the customer relationship management (CRM) sys-

tem, will then have to start by checking whether con-

sent for this type of processing is available.

To implement this last requirement, it is therefore

sometimes recommended to introduce an architecture

layer where relevant processing requests are checked

to verify that consent has been given, similar to and

possibly in combination with checking user authori-

sations.

The other legal bases for processing of personal

data do not lead to any speciﬁc software requirements

beyond those of requirement C-1 above.

Fairness and Transparency. The principle of fair-

ness is rather vague and therefore results in the fol-

lowing, also rather vague, software requirement:

Requirement (F-8 No Surprising and Unexpected

Processing). The system shall not perform any pro-

cessing of personal data that is surprising or un-

expected to the data subject. It shall not perform

any processing that unfairly exploits the imbalance of

power between controller and data subject.

Finally, the principle of transparency aims at mak-

ing sure that data subjects know what data about them

are processed and how. Although the principle itself

is rather vague as well, the rights of the data subjects

listed in Sect. 4 help to translate it into speciﬁc re-

quirements.

3.2 Purpose Limitation

The principle of purpose limitation, in GDPR speci-

ﬁed in Art. 5(1)b, states that the purpose of processing

personal data must be deﬁned in advance, before col-

lecting the data, and the data may not be used for any

purpose inconsistent with the initial purpose. Process-

ing data for a new, different purpose therefore is not

excluded altogether, but there must be a direct rela-

tionship between the original and the new purpose.

Requirement (C-2 Document Purpose). Before any

personal data are collected or processed by the sys-

tem, the controller shall deﬁne and document the pur-

pose to be achieved.

Again, the adequate place for this documentation

in general is the records of processing activities. Fur-

thermore, this purpose should be available to the de-

velopment organisation before starting development.

Requirement (C-3 Purpose Limitation). If the system

performs some form of processing different from the

one initially deﬁned, the controller shall ensure that

it is analysed, justiﬁed and documented why the new

purpose is considered consistent with the old one.

Of course, there must also be an adequate legal

basis for the new processing. Coming back to the

case of an online shop, a common objective is to per-

form various analyses on the customer data collected.

To a very limited extent, this may be done based on

the condition of legitimate interest, but beyond that,

consent by the customer is usually needed. In many

cases, it will be easier and more efﬁcient to work with

anonymised data instead.

3.3 Data Minimization

According to the principle of data minimization, per-

sonal data must be “adequate, relevant and limited to

what is necessary in relation to the purposes for which

they are processed” (Art. 5(1)c GDPR). Therefore,

only those data may be collected and processed that

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

260

are necessary for the deﬁned purpose of processing,

while storing data “just in case” is not allowed. This

can be quite a challenge in the context of big data and

data science where one often collects data to ﬁnd out

later what information may be gained from them.

The principle of data minimization leads to the

following software requirement:

Requirement (C-4 Data Minimization). The system

may only collect and process data that are necessary

for the deﬁned and documented purpose. This in-

cludes each individual data attribute as well as the

overall data set.

In the case of an online shop, the shop may offer

to answer customer questions via a contact page. To

answer any such questions, it is usually sufﬁcient to

know either the email address or the telephone num-

ber, and collecting any personal data beyond that must

therefore at least be optional, stating clearly what

these data are used for, or better not done at all.

As discussed in Sect. 2.1, it may be useful to

convert personal data into anonymous or at least

pseudonymous data in order to protect them against

unauthorised usage:

Requirement (C-5 Data Anonymisation and Pseudo-

nymisation). The system should store data in anony-

mised or at least pseudonymised format where this is

possible without limitation for the intended purpose.

As mentioned before, pseudonymous data are

still personal data and need to be protected accord-

ingly, and even with anonymous data, protecting the

data against unauthorised access still is recommended

where possible since experience shows that anonymi-

sation often can be broken.

In order to analyse the movement of visitors to the

website of an online shop (web analytics, as opposed

to user tracking), the IP addresses of the visitors are

usually anonymised by deleting part of them. This is

still sufﬁcient to identify subsequent movements by

the same visitor, but does not allow the identiﬁcation

of visitors.

3.4 Accuracy

The principle of accuracy (Art. 5(1)d GDPR) may be

summarised as follows:

Requirement (Q-1 Accuracy). Data processed and

stored shall be accurate and, where relevant, kept up

to date.

Additionally, the following requirements are im-

plied:

Requirement (F-9 Rectifying Data). The system

shall provide the controller with the ability to rectify

or update data.

In the case of an online shop, this mainly refers to

the fairly obvious need to be able to update or correct

customer data such as their address, but also infor-

mation such as customer interests and preferences, or

about customer not having paid previous bills if this

turns out to be a mistake.

Requirement (F-10 Consistency Check). The system

should check input data for consistency to recognize

and prevent invalid input.

This requirement is not legally required but helps

to implement requirement Q-1. An approach to im-

plement F-10 is the use of drop-down lists where pos-

sible rather than allowing free text.

In most cases, implementing the principle of ac-

curacy is also in the controller’s own interest, similar

to data minimization. Deﬁning it as a legal require-

ment ensures that accuracy is also aimed for in those

cases where the controller has little or no own interest

in keeping the data accurate.

3.5 Storage Limitation

The principle of storage limitation (Art. 5(1)e GDPR)

extends data minimization by a temporal view and

states that personal data may only be stored as long as

they are needed for their deﬁned purpose. After that,

they must be deleted or at least turned into anonymous

data.

Requirement (F-11 Identify Data no Longer Re-

quired). The system shall provide the controller with

the ability to identify any personal data no longer re-

quired.

For example, this includes identifying the data

whose required retention period has passed.

Since the controller may choose between anony-

mising and deleting data that are no longer needed,

the following two requirements are expressed as

should-requirements where at least one of them shall

be satisﬁed in any individual case identiﬁed by F-11.

Requirement (F-12 Anonymisation of Data). The

system should provide the controller with the ability

to transform stored personal data no longer required

into anonymous data. The anonymous data shall be

in a format that prevents de-anonymisation with real-

istic effort. When data are anonymised, the system

shall replace all copies of the original data by the

anonymised data, unless they are deleted.

This requirement is similar to C-5, but while C-

5 applies to an entire data collection, F-12 refers to

selected parts of a data collection, possibly even in-

dividual records. Again looking at an online shop as

an example, F-12 requires that old customer and or-

der data are anonymised (or deleted, see F-13 below)

Translating Data Protection into Software Requirements

261

once legal retention periods have run out, while cur-

rent customer and order data of course must be pre-

served.

Requirement (F-13 Deletion of Data). The system

should provide the controller with the ability to delete

personal data identiﬁed as no longer required, includ-

ing all instances of the data such as backups.

3.6 Integrity and Conﬁdentiality

In spite of their close relationship, IT security and

data protection start from fundamentally different per-

spectives. The goal of IT security is to protect data

and infrastructure against negative inﬂuence from

outside, including protection against unauthorised ac-

cess. Data protection, on the other hand, aims at pro-

tecting individuals against misuse of their data, which

implies restricting authorised access as well as pro-

tecting against unauthorised access. To a large extent,

IT security is needed to achieve data protection, but it

is not sufﬁcient.

GDPR expresses this relationship in the princi-

ple of integrity and conﬁdentiality (Art. 5(1)f) which

requires “adequate security”

. Taken almost liter-

ally from GDPR, the resulting software requirement

states:

Requirement (Q-2 Integrity and Conﬁdentiality).

The system shall provide adequate security of per-

sonal data, including protection against unauthorised

or unlawful processing and against accidental loss,

destruction or damage.

Note that, in spite of the name of the GDPR prin-

ciple, this includes the third dimension of IT security,

namely availability, in addition to the dimensions in-

tegrity and conﬁdentiality.

Particularly important for data protection are mea-

sures such as the restrictive handling of access rights,

the secure storage of access data (for example no stor-

age of passwords in plain text), and encryption of data

at least when transferring them between systems.

3.7 Accountability

Accountability is a fairly new principle of data pro-

tection that is not currently widespread in other data

protection legislation. It states that it is not sufﬁcient

to implement data protection but controllers need to

Of course, this immediately leads to the question of

what is considered adequate. The answer obviously de-

pends on the speciﬁc environment and the personal data in-

volved, but in many cases, the requirements on information

security management systems as deﬁned by ISO/IEC 27001

provide a good guideline.

be able to show that they do so by providing adequate

documentation such as the “records of processing ac-

tivities” introduced in Sect. 5.1 below.

Requirement (C-6 Documentation). The system, in

particular its processing of personal data, shall be

documented and this documentation be versioned and

kept up to date.

Versioning is important in this context in order to

show, in case of problems, what processing was per-

formed at a certain point in time in the past.

Apart from satisfying the legal requirements, such

documentation helps to identify the personal data pro-

cessed and the resulting needs for data protection

measures.

4 RIGHTS OF DATA SUBJECTS

Based on the data protection principles above, data

protection deﬁnes a set of rights of the data subjects.

These help to implement the principles and therefore

in some cases lead to the same software requirements

as described above.

For reasons of space, only a brief list of the rele-

vant rights can be included in the current paper. How-

ever, in most cases these rights are fairly speciﬁc as

expressed in GDPR, which makes it easier to trans-

late them into software requirements compared to the

data protection principles:

• Rights to transparency and information (Art. 12–

15 GDPR)

• Right to rectiﬁcation (Art. 16 GDPR)

• Right to erasure (right to be forgotten) (Art. 17

GDPR)

• Right to restriction of processing (Art. 18 GDPR)

• Right to data portability (Art. 20 GDPR)

• Right to object (Art. 21 GDPR)

• Right to request manual decision-taking (Art. 22

GDPR)

In most cases, these rights of the data subjects do

not apply in general but only under certain conditions.

However, these are usually conditions that have to be

checked on the organisational level rather than by the

software. As a result, they are not directly included in

the software requirements but need to be described as

functions initiated by the controller (or, in some cases,

the user/data subject).

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

262

5 FURTHER REQUIREMENTS

In addition to the principles of data protection and the

rights of the data subjects, GDPR deﬁnes a number

of further data protection requirements. In the follow-

ing, we summarise those that inﬂuence the software

requirements.

5.1 Records of Processing Activities

The “records of processing activities” as required by

Art. 30 GDPR contain a summary of the processing

of personal data that is performed by the organisa-

tion, with attributes including the categories of data

processed (such as customer addresses, health data of

employees etc.), and the technical and organisational

measures taken to protect these data. This is related

to requirement C-6, but with a different focus: while

C-6 is concerned with the documentation of individ-

ual systems and more detailed, requirement C-7 puts

the focus on providing an overview of the different

systems and processes in use, and the personal data

processed by them.

Requirement (C-7 Records of Processing Activities).

The controller shall document in the records of pro-

cessing activities the processing performed by the sys-

tem, including the purpose of processing, the cate-

gories of affected data subjects and of personal data,

the recipients of the data, and the technical and or-

ganisational measures taken to protect these data.

Although this is not a requirement to be imple-

mented by software development itself, the controller

will typically need support from software develop-

ment in order to implement this requirement ade-

quately.

5.2 Data Transfer to Third Parties

Another set of important requirements which however

are too complex to be covered fully within this paper

concern the transfer of data to third parties. In the

context of software development, this may for exam-

ple refer to the use of cloud or other external services,

or to the use of certain plug-ins and SDKs which

transfer personal data to the provider of the plug-in

or SDK. The term “third party” includes any legally

separate unit even if it may belong to the same enter-

prise as the controller.

Software developers should however realise that

any such data transfer may lead to complex data pro-

tection questions, and should therefore be discussed

with the controller as well as data protection special-

ists before implementation. In particular, it is impor-

tant to check for unexpected or unwanted data transfer

as happens commonly when using third-party SDKs

in the development of web applications or mobile

apps, see for example (Englehardt et al., 2018).

Requirement (C-8 Data Transfer to Third Parties).

Any transfer of personal data to or from third parties

shall be identiﬁed. For any such data transfer, the le-

gal basis shall be identiﬁed and documented. In case

the legal basis is a controller-processor relationship,

a legal contract according to Art. 28 GDPR shall be

agreed.

Additional requirements apply if the data are to

be transferred outside the European Economic Area

(EEA)

. In this case, the transfer of personal data is

only allowed if the receiving country has an “adequate

level of data protection”, where GDPR deﬁnes a set of

conditions that may be used for verifying this property

(Art. 44–50 GDPR).

Requirement (C-9 Data Transfer Outside the EEA).

In case any personal data are to be transferred out-

side the European Economic Area, an adequate level

of data protection shall be veriﬁed.

5.3 Data Protection by Design / by

Default

The concept of data protection by design (Art. 25(1)

GDPR), also known as “Privacy by Design” (Cavou-

kian, 2011), may be summarised as follows:

Requirement (C-10 Data Protection by Design).

Measures to address data protection shall be taken

across the entire life cycle of the system, starting with

analysis and design.

The purpose of data protection by design is to en-

sure that data protection is taken into account from

the start rather than as an “add-on” at the end when

effective measures become too expensive and there-

fore are no longer feasible.An important step towards

implementing data protection by design therefore is

to address the requirements listed in this paper as part

of requirements analysis.

Closely related to data protection by design is data

protection by default (Art. 25(2) GDPR):

Requirement (Q-4 Data Protection by Default). The

system shall be conﬁgured such that only minimal per-

sonal data are collected and processed as necessary

for the relevant purpose. Any further data collection

and processing may only be performed if the user ex-

plicitly allows this by adapting the conﬁguration.

The EEA consists of the European Union plus the

EFTA states Iceland, Liechtenstein and Norway, and deﬁnes

the territorial scope of the GDPR.

Translating Data Protection into Software Requirements

263

An example for this is not to save the user prefer-

ences by default, unless the user sets a ﬂag that these

data should be saved and used.

For both concepts it is true that as of today,

they are not widely applied and there are many

counter-examples around, partly because these con-

cepts were only fairly recently introduced as legal re-

quirements. Nevertheless, any current software devel-

opment should adhere to these concepts, both to sat-

isfy user expectations and to prevent legal problems,

for example with the relevant supervisory authorities.

6 VALIDATION OF RESULTS

Since the GDPR requirements are expressed in a very

different way compared to software and software pro-

cess requirements, there is no formal way to validate

the results in this paper. To ensure the correctness of

the results, they were checked against the text of the

GDPR itself, supported by some legal commentaries

such as (K

uhlung and Buchner, 2018), and reviewed

by several experts.

More difﬁcult is the completeness of the results.

To validate the completeness, the results were com-

pared against different publications that address the

effects of data protection and GDPR requirements on

software development, in particular (Danezis et al.,

2014; Datatilsynet, 2017; Reid, 2017; Santala, 2017;

Simon and Moucha, 2019). The results of these com-

parisons were directly integrated into the results de-

scribed above, so that the version reported here al-

ready includes all requirements that had been identi-

ﬁed as missing.

7 CONCLUSIONS

As this paper shows, data protection and in particu-

lar the GDPR leads to a set of requirements that need

to be addressed in software development, including

functional requirements, quality (non-functional) re-

quirements and constraints. Although these require-

ments strictly speaking only apply to the processing

of personal data, a close look shows that this indeed

includes a large proportion of the data processed.

This implies that requirements analysts and soft-

ware developers need to take these requirements into

account and check which of them apply in their spe-

ciﬁc case. Although the requirements presented in

this paper will of course have to be adapted and ex-

tended for any speciﬁc software system, these require-

ments represent an advanced starting point for the

task, providing considerably more detail compared to

the GDPR (or other, similar legislation) itself.

REFERENCES

Cavoukian, A. (2011). Privacy by design. The 7 founda-

tional principles. Technical report, Information and

Privacy Commissioner of Ontario.

Danezis, G., Domingo-Ferrer, J., Hansen, M., Hoepman,

J.-H., Le M

etayer, D., Tirtea, R., and Schiffner, S.

(2014). Privacy and data protection by design—from

policy to engineering. Technical report, ENISA.

Datatilsynet (2017). Software development with data pro-

tection by design and by default.

Englehardt, S., Acar, G., and Narayanan, A.

(2018). Website operators are in the dark

about privacy violations by third-party scripts.

https://freedom-to-tinker.com/2018/01/12/website-

operators-are-in-the-dark-about-privacy-violations-

by-third-party-scripts/.

International Requirements Engineering Board (IREB)

(2017). IREB Certiﬁed Professional for Requirements

Engineering — Foundation Level. Syllabus Version

2.2.2. Technical report.

uhlung, J. and Buchner, B., editors (2018). Datenschutz-

Grundverordnung / BDSG. Kommentar (in German).

C.H. Beck, 2. edition.

Kneuper, R. (2019). Integrating data protection into

the software life cycle. In Franch, X., M

annist

T., and Mart

ınez-Fern

andez, S., editors, Product-

Focused Software Process Improvement. 20th Interna-

tional Conference, PROFES 2019, Barcelona, Spain,

November 27–29, 2019, Proceedings, pages 417–432,

Cham. Springer International Publishing.

Pohl, K. and Rupp, C. (2015). Requirements Engineering

Fundamentals. Rocky Nook, 2nd edition.

Reid, G. (2017). How to navigate the software development

life cycle under the GDPR. International Association

of Privacy Professionals (IAPP).

Santala, A. (2017). What should software engineers know

about GDPR?

Simon, K. and Moucha, C. (2019). Sicherheit und Daten-

schutz im Lebenszyklus von Informationssystemen

(in German). DuD Datenschutz und Datensicherheit,

43(2):97–101.

ICISSP 2020 - 6th International Conference on Information Systems Security and Privacy

264