nist sp 800-122, guide to protecting the confidentiality ... · any information relating to a data...

ICT Project

This project has received funding from the European Union’sHorizon 2020 research and innovation programme

The European Open Source Market Place

www.apphub.eu.com

Deliverable D4.4

Data Protection Compliance Guidelines

Project Number : 645096

Project Title : AppHub

Deliverable Number : D4.4

Title of Deliverable : Data Protection Compliance Guidelines

Nature of Deliverable : Report

Dissemination level : Public

Licence : Creative Commons Attribution 3.0 License

Version : 0.4

Contractual Delivery Date : January 1, 2016

Actual Delivery Date : January 10, 2016

Contributing WP : WP4

Editor(s) : Peter Deussen (Fraunhofer)

Author(s) : Peter Deussen (Fraunhofer)

Reviewer(s) : Cedric Thomas (OW2), Alexandre Lefebvre (UShareSoft)

AbstractThis report has the following objectives:

1. To provide an overview over the upcoming European level General Data ProtectionRegulation with the purpose to identify those parts that are relevant for the processing of PIIbe the target audience indicated above, and

2. to provide practical advice on how to implement technical measures that will increasecompliance with this regulation.

This report uses the upcoming General Data Protection Regulation of the European Unionas regulatory baseline document. The regulation is expected to be adopted early 2016. Fromthis time, it will replace national data protection regulations of the Member States, providinga single regulation for the whole of Europe.

Keyword listProtection of personally identifiable information, European General Data ProtectionRegulation, security, data subject rights

http://creativecommons.org/licenses/by/3.0/

Document History

Version Changes Author(s)

1 Outline Peter Deussen

2 Draft Peter Deussen

3 Final draft Peter Deussen

4 Final Peter Deussen

Document Review

Review Date Ver. Reviewers Comments

Outline 21/09/2015 0.1 PMB Accept

Draft 21/12/2015 0.2 Alexandre Lefebvre (UShareSoft)

Comments and editorialchanges

QA 21/12/2015 0.3 Alexandre Lefebvre (UShareSoft)

Editorial changes

Final 08/01/2016 0.4 PMB Accept

Glossary, acronyms & abbreviations

Item Description

NIST National Institute for Standards and Technology

GDPR General Data Protection Regulation

OECD Organisation for Economic Co-operation and Development

PII Personal Identifiable Information

OSS Open source software

Table of Contents

1. Introduction..........................................................................................................................1

1.1. Target Audience.............................................................................................................11.2. Objectives.......................................................................................................................11.3. Scope..............................................................................................................................11.4. Terminology....................................................................................................................11.5. Report Structure.............................................................................................................2

2. Personal Identifiable Information Protection and Security............................................2

2.1. The European General Data Protection Regulation......................................................32.2. Relevant Rights of Data Subjects...................................................................................32.3. General Obligations........................................................................................................5

3. Guidelines for Impact Assessment...................................................................................6

3.1. Risk Assessment Overview............................................................................................63.2. Factors............................................................................................................................7

4. Security Guidelines.............................................................................................................8

4.1. Generic Operational Safeguards....................................................................................84.2. Privacy-specific Safeguards...........................................................................................84.3. Security Controls..........................................................................................................10

5. Guidelines Related to Data Subjects Rights..................................................................11

5.1. Metadata for Transparency and Data Subject Information..........................................115.2. Effective Information and Rectification Mechanisms...................................................115.3. Effective Deletion Mechanisms....................................................................................125.4. Data Portability.............................................................................................................12

6. Privacy by Default and Design.........................................................................................13

6.1. Principles......................................................................................................................136.2. Guidelines.....................................................................................................................14

7. Conclusion.........................................................................................................................15

References............................................................................................................................15

1. Introduction

1.1. Target AudienceThis report details guidelines on data protection, security and standard compliance that are relevantfor a various actors:

Open source software (OSS) products are applied in contexts where personal identifiableinformation (PII) is collected, stored, transformed, correlated, or disseminated (activities wewill commonly refer to as “processing” throughout this report). Any software systemcomprising a user database falls into this category, as well as customer relationshipmanagement and enterprise resource management systems used in an enterprise computingenvironment. In addition, current research trends in the area of big data, internet of things, orsmart cities are likely to generate software artefacts used for PII processing.

Many research projects that produce software as described above conduct field trialsinvolving real users.

Finally, a large, well-managed open source project maintains a database of contributors andusers. Although consensus to publish information, e.g., on contributions, in a non-anonymizedway can in general safely assumed as given, the fact remains that contributors have the rightto object against such practice.

1.2. ObjectivesThis report therefore has the following objectives:

To provide an overview over the upcoming European level General Data ProtectionRegulation with the purpose to identify those parts that are relevant for the processing of PIIbe the target audience indicated above, and

to provide practical advice on how to implement technical measures that will increasecompliance with this regulation.

1.3. ScopeThis report uses the upcoming General Data Protection Regulation (GDPR) [EC 2012] of theEuropean Union as regulatory baseline document. The GDPR is expected to be adopted early 2016.From this time, it will replace national data protection regulations of the Member States, providing asingle regulation for the whole of Europe. Therefore, the choice of the GDPR as baseline isreasonable even if it may differ from the 2012 draft and updates of this document are required.

This report does not intend to replace a legal or other assessment of the compliance of projects ororganisations that provide or use OSS for the purpose of PII processing. It rather provides a set ofgood practices and guidelines that will help those projects and organisations to increase the degreeof compliance.

This report does not apply to public sector organisations which might have additional regulations toconsider. Similarly, for specific classes of sensitive PII such as health data of financial data,additional EU and national level regulations have to take into account.

1.4. Terminology Throughout this report, we are using the following terminology. If not indicated otherwise, the termslisted below are taken from the GDPR draft [EC 2012, Article 4] and adapted to consistently matchthe terminology used in this report (see footnotes).

Data subject. An identified natural person or a natural person who can be identified, directly orindirectly, by means reasonably likely to be used by the controller or by any other natural or legalperson, in particular by reference to an identification number, location data, online identifier or to oneor more factors specific to the physical, physiological, genetic, mental, economic, cultural or socialidentity of that person.

AppHub 1Grant agreement no: 645096

Personal Identifiably Data (PII). Any information relating to a data subject.1

Linked PII. PII about or related to a data subject that is logically associated with other informationabout the data subject.2

Linkable PII. PII about or related to a data subject for which there is a possibility of logicalassociation with other information about the data subject.3

ProcessingProcessing. Any operation or set of operations which is performed upon PII or sets of PII, whether ornot by automated means, such as collection, recording, organization, structuring, storage, adaptationor alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwisemaking available, alignment or combination, erasure or destruction.

Controller. Natural or legal person, public authority, agency or any other body which alone or jointlywith others determines the purposes, conditions and means of the processing of PII.

Processor. Natural or legal person, public authority, agency or any other body which processes PIIon behalf of the controller.

Recipient. Natural or legal person, public authority, agency or any other body to which the PII aredisclosed.

1.5. Report StructureSection 2 reviews the parts of the GDPR that are relevant regarding objecives and scope of thisreport. The obligation of obtaining and understanding of the risks of the processing of PII in aparticular context is an important principle of the GDPR. Hence, Section 3 provides guidelines withregard to impact assessment. Security is considered in Section 4, measures to ensure data subjectrights are discussed in Section 5. The principle of “privacy by design and default” is discussed inSection 6. The final Section 7 draws conclusions.

2. Personal Identifiable Information Protection and SecurityPII protection regulations “lay down rules relating to the protection of individuals with regard to theprocessing of PII and rules relating to the free movement of personal data.”4 Hence, PII protectiondoes not apply (a) to data relating to an enterprise, organisation, state, etc., and (b) to data that arenot related to a specific person such as environmental data, traffic information, etc.

PII protection is related but not identical to information security. Information security copes withtechnical measures to achieve three main objectives:5

Confidentiality. Preserving authorized restrictions on information access and disclosure, includingmeans for protecting personal privacy and proprietary information.

Integrity. Guarding against improper information modification or destruction, and includingprovisioning of information non-repudiation and authenticity.

Availability. Ensuring timely and reliable access to and use of information.

PII protection, as opposed to security, is not a technical but a legal term comprising obligations andprohibitions. These may imply technical solutions (e.g., for security), but are necessarily presented ina technical neutral way. PII protection therefore is related to:

(1) The obligation to data controllers and processors to ensure that certain rights of data subjectscan be exercised by them.

(2) The prohibition to process PII in a way that violates the rights of data subjects, or allow thatanother party performs such processing.6

1The GDPR uses the term “personal data” instead of “personal identifiable information”.2From [NIST 2010], adapted to match the terminology used in this report.3From [NIST 2010], adapted to match the terminology used in this report.4[EC 2012, Art. 1, § 1]5[NIST 2014]6The German national general data protection law defines the fundamental principle of “informational self-determination”that grants German citizens the right to decide what information about himself should be communicated to others and underwhat circumstances. Although this term has not been adopted in the GDPR, it effectively supports this principle. A similar


Hence, issue (1) is related to “the other half of PII”, namely measures to ensure that (technical ororganisational) measures are available for data subjects to exercise their rights.

2.1. The European General Data Protection RegulationThe GDPR requires7 that the processing of PII is done “lawfully, fairly and in a transparent manner”.PII must be collected for “specified, explicit and legitimate purposes and not further processed in away incompatible with those purposes”. Furthermore, the principle of data minimization has to beapplied: PII processing has to be “adequate, relevant, and limited to the minimum necessary inrelation to the purposes for which they are processed”. The data processor has to make sure that PIIare “accurate and kept up to date”, and “kept in a form which permits identification of data subjectsfor no longer than is necessary for the purposes for which the personal data are processed.”

The GDPR permits the processing of PII if on of the following conditions is satisfied:8,9

(a) The data subject has given his/her consent to the processing of PII;

(b) processing is necessary for the performance of a contract to which the data subject is party orin order to take steps at the request of the data subject prior to entering into a contract;

(c) processing is necessary for compliance with a legal obligation to which the controller is subject;

(f) processing is necessary for the purposes of the legitimate interests pursued by a controller, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data […].

Hence, for practical purposes related to the processing of PII by the target audience of this report (c.f.Section 1.1) can be considered as lawful if the data subject has provided explicit consent; theobligation to obtain this consent (and to proof that it has been given) lies by the data controller.10

Consent can be withdrawn by the data subject at any time.11 Note that (f) allows, e.g., cloud serviceproviders to process PII for marketing purposes, to improve their service quality, etc.

2.2. Relevant Rights of Data SubjectsThe GDPR defines a number of rights of data subjects, and moreover, requires for controllers andprocessors the establishment of procedures and mechanisms to ensure that these rights caneffectively exercised by the data subjects.12

2.2.1. Access Rights and Transparency

“The controller shall provide any information and any communication relating to the processing ofpersonal data to the data subject in an intelligible form, using clear and plain language, adapted tothe data subject [...].”13

On request by the data subject, the data controller is obliged to provide the information whether PIIrelating to the data subject are processed, and if so, additionally:14

(a) the purposes of the processing;

(b) the categories of PII concerned;

principle is acknowledged by French data protection regulations, c.f.. http://www.cnil.fr/documentation/textes-fondateurs/loi78-17/7[EC 2012, Art. 5] for all citations in this paragraph.8[EC 2012, Art. 6, § 1]; three additional conditions are specified here as well, namely: (d) processing is necessary in order toprotect the vital interests of the data subject; (e) processing is necessary for the performance of a task carried out in thepublic interest or in the exercise of official authority vested in the controller. 9Furthermore, the GDPR imposes specific rules for processing of PII related to: (a) freedom of expression [EC 2012, Art.80]; (b) health data [EC 2012, Art. 81]; (c) employment context [EC 2012, Art. 82]; (d) historical, statistical or scientificresearch purposes [EC 2012, Art. 83]; (e) secrecy [EC 2012, Art. 84]; (f) Existing data protection rules of churches andreligious associations [EC 2012, Art. 85].10[EC 2012, Art. 7, § 1]11[EC 2012, Art. 7, § 3]; withdrawal of consent does not invalidate the lawfulness of processing prior to the withdrawal.12[EC 2012, Art. 12]13[EC 2012, Art. 11, § 2]14[EC 2012, Art. 15, § 1]


(c) the recipients or categories of recipients to whom the PII are to be or have been disclosed, inparticular to recipients in third countries;

(d) the period for which the personal data will be stored;

(e) the existence of the right to request from the controller rectification or erasure of personaldata concerning the data subject or to object to the processing of such personal data;

(f) the right to lodge a complaint to the supervisory authority and the contact details of thesupervisory authority;

(g) communication of the personal data undergoing processing and of any available informationas to their source;

(h) the significance and envisaged consequences of such processing, at least in the case ofmeasures referred to [automated profiling]15.

Data subjects have the right to obtain from the controller information on the related PII that are beingprocessed. Request made in in electronic form have to be answered electronically as well if nototherwise requested by the data subject.16

2.2.2. Right for Rectification

Data subjects have the right to obtain correction of incorrect or inaccurate PII from the controller, andto the completion of incomplete PII.17

2.2.3. Right to be Forgotten and to Erasure

Data subject have the right to obtain the deletion of PII relating to them and the abstention fromfurther dissemination of such data if:18

(a) the data are no longer necessary in relation to the purposes for which they were collected orotherwise processed;

(b) the data subject withdraws consent on which the processing is based, or when the storageperiod consented to has expired, and where there is no other legal ground for the processingof the data;

(c) the data subject objects to the processing of personal data;

(d) the processing of the data does not comply with the GDPR for other reasons.

It is important that erasure also applies to data that have been made public: In this case, “thecontroller has to take take all reasonable steps, including technical measures [...], to inform thirdparties which are processing such data, that a data subject requests them to erase any links to, orcopy or replication of that personal data.”19,20

2.2.4. Right to Data Portability

If PII are processed electronically and in a structured and commonly used format, the data subjectcan obtain from the controller a copy of the relating PII “in an electronic and structured format whichis commonly used and allows for further use by the data subject.”21

Furthermore, for those PII that have been provided according to consent or contract, data subjectshave the right to transfer PII into another automated processing system, in a commonly used format,without hindrance from the controller from whom the personal data are withdrawn.22

15Modified by the authors as indicated. The term “profiling” covers fully automated measures that analyse, evaluate, orpredict aspects of natural persons, such as work performance, economic situation, location, health, personal preferences,reliability or behaviour. 16[EC 2012, Art. 15, § 2]17[EC 2012, Art. 16]18[EC 2012, Art. 17, § 1], slightly modified by the authors for editorial reasons.19[EC 2012, Art. 17, § 2]20[EC 2012, Art. 17, § 3 – § 8] specify exceptions that allow the controller to delay the deletion of PII or take alternative measures such as restricted processing. 21[EC 2012, Art. 18, § 1]22[EC 2012, Art. 18, § 2]


2.2.5. Right to Object

The GDPR further defines a right to object that is applicable in cases where PII processing is basedon the protection of vital interests of the data subject, related to public interests, or legitimateinterests of the controller, i.e., in those cases where a consent by the data subject, a contractualrelationship to the controller, or a legal obligation to process those data of the controller cannot beassumed. These issues are of relevance for the target audience of this report in rare cases only, withthe exception exemplified in paragraph 2 of Article 19: “Where personal data are processed for directmarketing purposes, the data subject shall have the right to object free of charge to the processing oftheir personal data for such marketing. This right shall be explicitly offered to the data subject in anintelligible manner and shall be clearly distinguishable from other information.”

2.2.6. Measures Based on Profiling

The GDPR elaborates that natural persons have the right of not being subject to profiling, i.e.,measures of legal relevance or other significant affects to this person, which are based solely onautomated processing evaluating “certain personal aspects relating to this natural person or toanalyse or predict in particular the natural person's performance at work, economic situation,location, health, personal preferences, reliability or behaviour.”23 Such measures are permitted only

(1) in the context of a contract,24

(2) if authorized by a relevant25 law,

(3) is based on the data subject's consent.26

2.3. General ObligationsIn addition to rights granted to data subjects, the GDPR addresses a number of general obligations.

2.3.1. Privacy by Design and by Default

Controllers have – within the restrictions of the current state of the art and cost constraints – toimplement appropriate technical and organisational measures and procedures to ensure complianceto the GDPR and to protect data subject rights. Mechanisms for data minimization and dataavoidance should be in place, related both to the amount of the data and the time of their storage.27

2.3.2. Documentation

Controllers and processors are obliged to maintain a documentation comprising the following items:28

(a) the name and contact details of the controller, or any joint controller or processor, and of therepresentative, if any;

(b) the name and contact details of the data protection officer, if any;

(c) the purposes of the processing, including the legitimate interests pursued by the controllerwhere the processing is based on legitimate interests of the controller;29

(d) a description of categories of data subjects and of the categories of personal data relating tothem;

(e) the recipients or categories of recipients of the personal data, including the controllers towhom personal data are disclosed for the legitimate interest pursued by them;

(f) where applicable, transfers of data to a third country or an international organisation,including the identification of that third country or international organisation and, in case oftransfers required by the legitimate interests30 pursued by the controller or the processor, thedocumentation of appropriate safeguards;

(g) a general indication of the time limits for erasure of the different categories of data;

23[EC 2012, Art. 20, § 1]24[EC 2012, Art. 20, § 2(a)] provides further explanation on necessary conditions and safeguards25As exemplified in [EC 2012, Art. 20, § 2(b)]26[EC 2012, Art. 20, § 2(c)] provides further explanation on necessary conditions and safeguards27[EC 2012, Art. 23]28[EC 2012, Art. 28, § 2], modified by the authors for editorial reasons29Explained in [EC 2012, Art. 6, § 1(f)]30Explained in [EC 2012, Art. 44, § 1(h)]


(h) the description of mechanisms to validate the effective implementation of the GDPR by thecontroller.31

2.3.3. Security Requirements

The controller and the processor are obliged – within the restrictions of the current state of the artand cost constraints – to implement appropriate technical and organisational measures to ensure alevel of security appropriate to the risks represented by the processing and the nature of the PIIunder consideration.32

Security breaches have to be reported within 24 hours after detection to the supervising authority.33 Ifdata subjects are concerned by a breach, they have to be informed with out undue delay as well.34

2.3.4. Data Protection Impact Assessment

The GDPR identifies a number of classes of procession operations for which processors andcontrollers are obliged to perform a specific impact analysis:35

(a) […] systematic and extensive evaluation of personal aspects relating to a natural person orfor analysing or predicting in particular the natural person's economic situation, location,health, personal preferences, reliability or behaviour, which is based on automatedprocessing and on which measures are based that produce legal effects concerning theindividual or significantly affect the individual;

(b) information on sex life, health, race and ethnic origin or for the provision of health care,epidemiological researches, or surveys of mental or infectious diseases, where the data areprocessed for taking measures or decisions regarding specific individuals on a large scale;

(c) monitoring publicly accessible areas, especially when using optic-electronic devices (videosurveillance) on a large scale;

(d) personal data in large scale filing systems on children, genetic data or biometric data.

The GDPR further requires a general description of the processing option, and “an assessment ofthe risks to the rights and freedom of data subjects, the measures envisaged to address the risks,safeguards, security measures and mechanisms to ensure the protection of PII”.36

3. Guidelines for Impact Assessment

3.1. Risk Assessment OverviewA great variety of methodologies for risk assessment and mitigation for PII protection is available. Acomprehensive account is far beyond the scope of this report. The reader is referred to [IPL 2014] fora summary of relevant regulations, standards, and best practices. In this section, we are going toprovide a generic overview over risk management and point out a number of issues related to PIIprotection.

Usually, risk analysis and assessment is based on:

(1) The identification of a certain risk (What can happen?).

(2) The assignment of an impact level (How severe are the results of a risk if it becomesimmanent? E.g., minimal, moderate, severe).

(3) The assignment of a likelihood (How possible is it that a risk becomes immanent at all? E.g.,certain, possible, unlikely).

Likelihood and impact level can be combined algebraically to obtain a criticallity index for a certainrisk:

Index minimal moderate severe

31Rephased by the authors for editorial reasons32[EC 2012, Art. 30, § 1]33[EC 2012, Art. 31, § 1]; [EC 2012, Art. 31, § 3] specifies the information that are to be reported. 34[EC 2012, Art. 32], restrictions to the obligations to inform data subjects are laid out in this article as well.35[EC 2012, Art. 33, § 2]36[EC 2012, Art. 33, § 3]


certain medium high high

possible low medium high

unlikely low low medium

Risks cannot always be avoided. In general, the following options to deal with risks are available.

Avoidance. Eliminate of a risk, or withdraw from the project or process that imposes the risk.

Reduction. Implementation of measures to decrease the likelihood of a risk or to reduce the impactof its consequences.

Sharing. Transfer the responsibility of a risk (outsource) or insure against it.

Retention. Accept the risk and budget for its consequences.

Having provided this overview, it should be noted that “risk management does not alter rights orobligations. Rather, it is a valuable tool for calibrating the implementation of and compliance withprivacy requirements, prioritising action, raising and informing awareness about risks, identifyingappropriate mitigation measures, […] [leading to a] scalable and proportionate approach tocompliance”.37

3.2. FactorsA number of factors can be identified that are important to identify privacy risks, their likelihood andimpact.38

Identifiability. How easy is it to identify a specific data subject given a set of data related to a largergroup of individuals? For instance, finger print data are very likely to single out a data subject within alarge group of individuals for which those data are available, while a ZIP code or a birth data onlynarrows down the set of individuals. It is important that correlating various attributes with “lowresolution” can significantly increase identifiability.

Quantity. How many individuals are effected by an illegitimate exposure of PII, e.g., to the publicInternet? Exposure of a small number of records will have lesser impact, both in terms of thecollective harm done to the data subjects concerned and the reputation of the breached organization.It should be noted that a risk of exposure cannot be ignored (or assessed as less critical) onlybecause a small number of data subjects is concerned, but that exposure of large numbers ofrecords however should be avoided by additional measures that provide stronger security.

Data Field Sensitivity. How sensitive is a certain data filed within a record of PII, and how sensitiveare they in combination? For instance, data on a credit card number is less sensitive in isolation thatin connection with the expiration date of the card and the name of the account's holder.

Context of Use. To which purpose are PII processed? Use contexts include statistical analysis,eligibility for benefits, administration of benefits, research, tax administration, or law enforcement. PIIprocessing for statistical purposes and research does leaves concerned data subjects lessvulnerable in general than those processed, e.g., for benefits administration.

Regulatory Obligations. In addition to (nowadays) national general data protection regulations andthe GDPR, organisations processing specific classes of data such as health data, insurance relateddata, financial data (e.g., banks), or those relevant for law enforcement are subject to additionalregulatory obligations that need to be taken into account.

Access to and Location of PII. Who is authorized to access PII, and by what means? Access bymultiple people and systems increases the likelihood that PII are compromised. Moreover, if PII arestored or regularly transported between different locations (e.g., by employee's laptops and mobilddevices), additional opportunities for unauthorized access and availability occur.

Geographic Location. The GDPR aims on a free flow of information within Europe. Transfer of PII tonon-member states is possible under certain conditions.39

37[IPL 2014], emphasises by the authors38[NIST 2010]39C.f. [EC 2012, Articles 40 – 45]


4. Security Guidelines

4.1. Generic Operational SafeguardsThis report concentrates on technical measures to improve PII protection regulation compliance.However, even the best mechanisms have to complemented by operational guidelines that makesure that they are applied in an effective and comprehensive way. In this section, we discuss twobest practices that provides an operational baseline for projects and organisations processing PII.

Policy and Procedure Creation. Policies aim at providing guidance on the proper handling of PII.Procedures underline them by concrete measures on how to apply them within an organization‘s orproject's environment: the definition of policies and associated procedures for the following topicsshould be considered.40

Access rules for PII within a system.

PII retention schedules and procedures.

PII incident response and data breach notification.

Privacy in the system development life cycle process.

Limitation of collection, disclosure, sharing, and use of PII.

If applicable, consequences for failure to follow privacy rules of behaviour.

Awareness, Training, and Education. Awareness efforts are designed to change behaviour orreinforce desired PII practices. The goal of training is to build knowledge and skills that will enablepersonal actively working with PII to follow related procedures, and to apply tools and mechanisms.Depending on the roles and functions involving PII, important topics to address may include:41

The definition of PII.

Applicable privacy laws, regulations, and policies.

Restrictions on data collection, storage, and use of PII.

Roles and responsibilities for using and protecting PII.

Appropriate disposal of PII.

Sanctions for misuse of PII.

Recognition of a security or privacy incident involving PII.

Retention schedules for PII.

Roles and responsibilities in responding to PII-related incidents and reporting.

A guideline for research projects and those concerned with the development of OSS products is atleast to provide a documentation covering the above topics (if appropriate) as training material forprojects members.

4.2. Privacy-specific SafeguardsMinimizing the Use, Collection, and Retention of PII. Data minimisation or-if possible-avoidance isa basic privacy principle.42 Indeed, limiting the collection of data collections to the least amountnecessary, negative consequences in the event of a data breach can be reduced. It also reflects thefact that PII collection and processing is lawful only if performed in the context of a concrete purpose.Therefore, the total amount and categories of PII used, collected, and maintained must beconsidered: if they do not serve a concrete purpose, or this purpose can be achieved without thesedata, they should be deleted.

Regular review of previously collected PII to determine whether the PII are still relevant andnecessary should be performed.

40[NIST 2010]41Ibid.42C.f. Section 2.1


In many cases (e.g., with regard to retention periods), automated watchdogs can be deployedthat delete unnecessarily stored PII or notify system administrators when PII needs to bedeleted.

De-identification. Keeping complete data records is not always necessary. For tasks related toresearch, resource planning, and examinations of correlations and trends only a small number ofinformation items within a data record are needed. In those cases, de-identification techniques canbe applied to reduce the risk of disclosure of PII. The term de-identified information is used todescribe records that have had enough PII removed or obscured, such that the remaining informationdoes not identify a specific individual. In many cases, de-identified data however can be re-identifiedby using a code, algorithm, or pseudonym that is assigned to individual records. Therefore, and asopposed to anonymised PII, de-idenfied PII are still personally identifiable information. A common de-identification technique for obscuring PII is to use a one-way cryptographic function, also known as ahash function. Good practices related to de-identified data are:43

Re-identification mechanisms and information are maintained in a separate system, withappropriate controls in place to prevent unauthorized access.

The data elements are not linkable, via public records or other reasonably available externalrecords, in order to re-identify the data.

Anonymizing PII. The GDPR addresses the topic of data anonymisation as follows:44

The principles of protection should apply to any information concerning an identified or identifiableperson. To determine whether a person is identifiable, account should be taken of all the meanslikely reasonably to be used either by the controller or by any other person to identify the individual.The principles of data protection should not apply to data rendered anonymous in such a way thatthe data subject is no longer identifiable.

Hence, anonymised data can be used for research or development purposes, or to improve servicequality, without taking into account PII protection issues, and a general recommendation is to usedata anonymisation as much and as soon as possible.

Data anonymisation involves the application of statistical disclosure limitation techniques to ensurethe data cannot be re-identified, such as:

Generalizing the Data. Making information less precise, such as grouping continuous values.

Suppressing the Data. Deleting an entire record or certain parts of records.

Introducing Noise into the Data. Adding small amounts of variation into selected data.

Swapping the Data. Exchanging certain data fields of one record with the same data fields ofanother similar record (e.g., swapping the ZIP codes of two records).

Replacing Data with the Average Value. Replacing a selected value of data with theaverage value for the entire group of data.

It should however be noted that data correlation techniques allow for the de-anonymisation of data.Therefore, it is reasonable to perform a risk analysis for anonymised data to assess the likelihoodand impact when de-anonymisation techniques (also in connection with additional data from othersources) are applied.

This good practice is in particular important for projects concerned with open data, and for projectsthat collect large amounts of PII for statistical processing. For those projects, it is important to assess:

The technical difficulty to re-identify a certain data subject based on the data publishedopenly;

The impact of the disclosure of the identity of the data subject (for instance, if the sameinformation is lawfully available elsewhere, disclose is not an issue);

Apply the general “fallback” to obtain an informed consent of data subjects.

Regular Privacy Impact Assessments

43[NIST 2010]44[EC 2012, point (23) on page 21]


4.3. Security ControlsThe term “security control” refers to a technical or an organisational measure that increases thesecurity of an IT system. There are several frameworks and standards providing information andguidelines on security controls available, including:

The ISO 27000 standards family.45

The German Baseline Protection (“IT-Grundschutz”) Catalogue.46

The NIST Special Publication “Security and Privacy Controls for Federal Information Systemsand Organizations” [NIST 2013].

Since the latter publication [NIST 2013]47 provides categorization of security controls more compactthan the other sources, we base our presentation on this document. Projects that are concerned withthe processing of PII however should take additional resources into account.

Access Enforcement. Organisations can control access to PII through access control policies andaccess enforcement mechanisms (e.g., access control lists). This can be done in many ways. Oneexample is implementing role-based access control and configuring it so that each user can accessonly the pieces of data necessary for the user‘s role. Another example is only permitting users toaccess PII through an application that tightly restricts their access to the PII, instead of permittingusers to directly access the databases or files containing PII. Encrypting stored information is also anoption for implementing access enforcement.

Separation of Duties. Organisations can enforce separation of duties for duties involving access toPII. For example, the users of de-identified PII data would not also be in roles that permit them toaccess the information needed to re-identify the records.

Least Privilege. Organisations can enforce the most restrictive set of rights/privileges or accessesneeded by users (or processes acting on behalf of users) for the performance of specified tasks.Concerning PII, the organization can ensure that users who must access records containing PII onlyhave access to the minimum amount of PII, along with only those privileges (e.g., read, write,execute) that are necessary to perform their job duties.

Remote Access. Organisations can choose to prohibit or strictly limit remote access to PII. If remoteaccess is permitted, the organization should ensure that the communications are encrypted.

User-Based Collaboration and Information Sharing. Organisations can provide automatedmechanisms to assist users in determining whether access authorizations match access restrictions,such as contractually-based restrictions, for PII.

Access Control for Mobile Devices. Organisations can choose to prohibit or strictly limit access toPII from portable and mobile devices, such as laptops, cell phones, and personal digital assistants(PDA), which are generally higher-risk than non-portable devices.

Auditable Events. Organisations can monitor events that affect the confidentiality of PII, such asunauthorized access to PII. For example, suppose that an organisation has a database containingthousands of records on employees' benefits. Instead of allowing a user to have full and directaccess to the database, which could allow the user to save extracts of the database records to theuser's computer, removable media, or other locations, the organization could permit the user toaccess only the necessary records and record fields.

Audit Review, Analysis, and Reporting. Organisations can regularly review and analyseinformation system audit records for indications of inappropriate or unusual activity affecting PII,investigate suspicious activity or suspected violations, report findings to appropriate officials, andtake necessary actions.

Identification and Authentication. Users can be uniquely identified and authenticated beforeaccessing PII. The strength requirement for the authentication mechanism depends on the impactlevel of the PII and the system as a whole. Organisations may allow remote access only with two-factor authentication where one of the factors is provided by a device separate from the computer

45See http://www.27000.org/ for more information.46See https://www.bsi.bund.de/EN/Topics/ITGrundschutz/itgrundschutz_node.html.47The following list of security controls is cited after [NIST 2013], with editorial changes done by the authors.


http://www.27000.org/

gaining access, and also may use a time-out function for remote access and mobile devices requiringuser re-authentication after a given period of inactivity.

Transmission Confidentiality. Organisations can protect the confidentiality of transmitted PII. Thisis most often accomplished by encrypting the communications or by encrypting the informationbefore it is transmitted.

Protection of Information at Rest. Organisations can protect the confidentiality of PII at rest, whichrefers to information stored on a secondary storage device, such as a hard drive or backup tape. Thisis usually accomplished by encrypting the stored information.

Information System Monitoring. Organisations can employ automated tools to monitor PII internallyor at network boundaries for unusual or suspicious transfers or events. An example is the use of dataloss prevention technologies.

5. Guidelines Related to Data Subjects Rights

5.1. Metadata for Transparency and Data Subject Information Obtaining an informed consent by the data subject on the processing of PII is one of the conditionsfor the their lawful processing (c.f. Section 2.1). For this, data subjects need to now:48

The purpose for which PII are collected and processed.

The categories for PII that are collected and processed.

The time frame in which the processing and storage takes place.

The geographic area where PII are stored.

The identities and contact details of the data controller and processor, and (if applicable) ofthe responsible data protection officer.

Recipients (or classes of recipients) different from the processors (in particular those in thirdcountries) to which PII are transferred.

This information is also needed to provide access rights for data subjects, it can be considered asgood practice to store these information as metadata along with the PII under processing, and toprovide automated access (e.g., as web interface).

Furthermore, data subjects should have access to the following generic information:

On the existence of the right to request from the controller rectification or erasure of personaldata concerning the data subject or to object to the processing of such personal data, and ofthe right to lodge a complaint to the supervisory authority and the contact details of thesupervisory authority;

on mechanisms and procedures to retrieve the PII relating to a data subject, and to erasethem;

on how to object against further processing of PII;

if PII are processed to automatically construct data subject profiles (in particular if linked withadditional data sources), the data subject should be informed about this, as well as about theusage of such profiles, and the parties that will have access to them.

The information provided to the data subject should be given in an intelligible form, in a language thatis adequate for the data subject (e.g., children). A good practice is to use localised texts with regardto the spoken language of data subject.

5.2. Effective Information and Rectification MechanismsInterfaces and Metadata. PII relating to a given data subject need to be identified if the data subjectrequests a copy of them. Hence, a mechanism should be in place (e.g., a link between the datasubject's identity and the relating PII) to find these data. In order to make PII relating to a particular

48Compare [EC 2012, Art. 14] for additional requirements and exceptions.


data subject identifiable, these data should be linked to the identity of this data subject, in additionwith the information described in Section 5.1.

In many cases, open source software is designed to provide Internet or cloud-based services or isintegrated into solutions that provides such services. Hence, access to PII by the relating datasubject should be possible in an automatic way. PII should be accessible via interfaces usingstandard protocol mechanisms (e.g., REST). Of course, access must be provided in a sufficientlysecure manner.

Access Control and Identity Management. The deployment of effective mechanisms to (a) validatethe identity of a certain data subject that seeks access to relating PII that is stored and processed,and (b) make sure that other persons or parties that have no authorisation to access those datacannot access them is mandatory. For access control, schemes more advanced than username/password authentication should be considered, such as multi-factor authentication.

Emphasis should be put on the use of standardised methods to ensure interoperability betweentechnical clients (data subject) and provider (processor). For identity management, a number ofstandards and related solutions already exist, such as:

Security Assertion Markup Language 2.0 (SAML 2.0);49

Kerberos;50

eXtensible Access Control Markup Language (XACML);51

For authentication based on biometric data: XML Common Biometric Format (XCBF)52

For more information on this topic, the reader is referred to the Cloud Security Alliance guideline[CSA 2010].

5.3. Effective Deletion MechanismsData subjects can object the processing of relating PII and to obtain the deletion of such data. Inaddition, if such data are no longer used for the purpose for which they have been collected orprocessed, erasure is required (c.f. Section 2.2.3).

Similar to information mechanisms, mechanisms for data erasure require at first the identification ofthe data that are to be deleted, hence keeping track of the identity of data subjects PII relate to isrequired. For data deletion in virtualised environments (such as clouds), an additional issue is tomake sure that data are really deleted since physical storage resources can be re-assigned othercustomers which – if physical and virtual resources are not sufficiently separated – can lead tounauthorized access to those data. Using standard technologies that are known to implement such aseparation can resolve this issue.

Another problem in particular for research projects based on the analysis of PII is that deletion oflarge amounts of data sets – e.g., due to a loss of trust of field trial or experimentation participants inthe project – can invalidate research results.53

5.4. Data PortabilityThe GDPR grants a right for data portability to data subjects for which – in addition to theestablishment of access and deletion mechanisms elaborated in Sections 5.2 and 5.3 – a number ofbest practices can be derived:

Standard formats and interfaces. Unfortunately, generic standards for data portability are notavailable yet. There are however a number of standards that apply to specific types of data, such asthe Resource Description Framework (RDF)54, Attention Profiling Mark-up Language (APML)55,49http://saml.xml.org/50http://www.kerberos.org/51http://xml.coverpages.org/xacml.html52https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xcbf53Hence, a (non-technical) guideline for projects that uses large amount of PII to conduct statistical research is:

Make sure to keep data subjects informed what happens to their data; Make sure that data processing is done within lawful boundaries, and that data subjects know that; Make sure to explain the personal or societal value of such data processing.

54http://www.w3.org/RDF/55https://web.archive.org/web/20131207134734/http://apml.areyoupayingattention.com/geeks/workgroup/


Outline Processor Markup Language (OPML)56, or Semantically-Interlinked Online Communities(SIOC)57, just to name a few.

Whenever possible, standardized interfaces, formats, and access protocols should be used. If this isnot possible, it is a good practice to provide a comprehensive documentation of data formats andinterfaces.

Porting data from the infrastructure of one processor to another (e.g., between different cloudproviders) should be as easy as possible. In an idealized scenario, a data subject can port data bycreating an account at the target provider, and then port all the data with a single mouse click.

Mass Data Transfer. If large amounts of data have to be transferred, the performance of thetransmission mechanism becomes an issue. Data compression should be considered. Also,providing an estimate of the expected transmission time (based on currently available end-to-endbandwidth) will be useful.

Transfer Security. Data transfer should be secured against interception by unauthorized parties,hence, end-to-end encryption is mandatory.

6. Privacy by Default and DesignThe GDPR requires for data controllers to implement appropriate technical and organisationalmeasures and procedures to ensure compliance to the GDPR and to protect data subject rights. Anumber of guidelines towards this end have already been discussed in the previous sections of thisreport. In this section, we are going to provide a deeper analysis of this topic.

6.1. PrinciplesPrivacy by design and default is an approach to protecting privacy by embedding it into the designspecifications of technologies, business practices, and physical infrastructures. That means buildingin privacy up front – right into the design specifications and architecture of new systems andprocesses. Ann Cavoukian, in her capacity as Information and Privacy Commissioner of Ontario, hasstated seven principles on privacy by design (including privacy by default):58

Proactive and preventative. Privacy by Design is characterized by proactive rather than reactivemeasures. It anticipates and prevents privacy invasive events before they happen. Privacy by designdoes not wait for privacy risks to materialize, nor does it offer remedies for resolving privacyinfractions once they have occurred: it aims at preventing them from occurring.

Privacy as default setting. Privacy by Design aims at delivering the maximum degree of privacy byensuring that personal data are automatically protected in any given IT system or practice. No actionis required on the part of the individual to protect their privacy-it is built into the system, by default.

Privacy embedded into design. Privacy by Design is embedded into the design and architecture ofIT systems and business practices. It is an add-on but an essential component of the corefunctionality being delivered. Privacy is integral to the system, without diminishing functionality.

No functional degradation. Privacy by Design aims at providing full functionality of IT systems inthe presence of effective PII protection. It avoids the presence of false dichotomies, such as privacyvs. security, demonstrating that it is possible to have both.

End-to-end data lifecycle protection. Privacy by Design, having been embedded into the systemprior to the first element of information being collected, extends securely throughout the entirelifecycle of the data involved – strong security measures are essential to privacy, from start to finish.This ensures that all data are securely retained, and then securely destroyed at the end of theprocess, in a timely fashion. Thus, Privacy by Design ensures secure end-to-end lifecyclemanagement of information.

Visibility and Transparency. Privacy by Design seeks to assure all stakeholders that whatever thebusiness practice or technology involved, it is, in fact, operating according to the stated promises and

56http://dev.opml.org/spec2.html57http://sioc-project.org/58Cited after [PBD 2011], rephrased by the author for the purpose of this report – compare subsequent footnotes.


objectives, subject to independent verification. Its component parts and operations remain visibleand transparent, to users and providers alike.

User centricity. Privacy by Design requires architects and operators to keep the interests of theindividual uppermost by offering such measures as strong privacy defaults, appropriate notice, andempowering user-friendly options.

6.2. GuidelinesBased on the principles described in the previous section, OASIS has developed a specification thatprovides guidance and requirements for engineers to document privacy objectives and associatedcontrol measures throughout the software development life cycle. We use this document as baselineto derive a set of guidelines for open source projects.

6.2.1. Pro-activity

Projects should assign the responsibility and accountability for issues related to PIIprocessing.

Resources to implement and evaluate privacy related functionalities have to be allocated forthe software project, recording who is responsible, accountable, consulted, or informed forvarious privacy-related tasks.

Relevant external sources of privacy requirements, including policies, principles, andregulations, have to be identified and documented.

Privacy requirements specific to the service/product that is being engineered, and theanticipated deployment environments, have to be identified and documented.

Privacy risk/threat model(s) including analysis and risk identification, risk prioritization, andcontrols should be clearly mapped to risks.

6.2.2. Privacy as Default Setting

Projects should identify all [categories of] data subjects as stakeholders.

Projects should clearly record the purposes for collection and processing, including retentionof personal data.

Projects should document expressive models of detailed data flows, processes, and expecteduser behaviors to understand the data/process interaction with external platforms, systems,APIs, or imported code.

Projects should describe privacy controls and privacy services/APIs and where they apply toprivacy functional requirements and risks.

A software retirement plan from a privacy viewpoint should be developed to make sure thatafter the retirement of the software under development privacy requirements are still met.

6.2.3. Privacy embedded into design

Projects should analyse their business or usage model showing traceability of personal dataflows for any data collected through new software services under development.

If possible the project should identify relevant privacy and security metrics.

Quality assurance measures should include and document privacy reviews.

6.2.4. No functional degradation

Projects should treat privacy as a functional requirement, i.e. functional software requirementsand privacy requirements should be considered together, with no loss of functionality.

Projects shall define tests for meeting privacy objectives, in terms of the operation andeffectiveness of implemented privacy controls or services.


6.2.5. End-to-end data lifecycle protection

Projects should analyse possible end-to-end scenarios for data collection, processing,transmission, etc., to understand protection requirements and threats. If possible, a datalifecycle model should be developed as part of the product documentation.

Projects should evaluate and document requirements, risk analysis, controls selection,architectures, design, implementation mechanisms, retirement plan, and sign-offs withrespect to privacy and security.

Projects should include security and privacy metrics designed in and/or deployed in thesoftware, or monitoring software, or otherwise in the organization, and across partneringsoftware systems or organizations.

6.2.6. Visibility and Transparency

Projects should be aware of the privacy policies and documentation of all other collaboratingstakeholders.

Projects should include description of contextual visibility and transparency mechanisms atthe point of contextual interaction with the user/data subject and other stakeholders for datacollection, use, disclosure, and/or elsewhere as applicable.

Projects should describe any measurements incorporated in the software, or monitoringsoftware, or otherwise to measure the usage and effectiveness of provided privacy optionsand controls, and to ensure continuous improvement.

Projects should describe placement of privacy settings, privacy controls, privacy policy(ies),and accessibility, prominence, clarity, and intended effectiveness.

6.2.7. User centricity

Projects should describe data subject privacy options, including (access) controls, and privacypreferences/settings.

Projects should describe notice, consent, and other privacy interactions at the earliestpossible point in a data transaction exchange with a user/data subject or her/his automatedagent(s) or device(s).

Projects should establish mechanisms to inform users upon their rights (c.f. Sections 2.2) andfunctionalities available to exercise them (c.f. Section 5).

7. ConclusionThe GDPR the will replace national data protections laws for the European member states, creating ahomogenized legal environment for the processing of PII. It will impact the whole digital Europeanmarket, including the market for open source software. In this report, we have derived a number ofgood practices aiming on technical measures that are suitable to increase conformance with theGDPR.

These measures concern two issues:

Information security,

data subject rights.

While developers of open source software and operators or Internet or cloud based services ingeneral take into account security measures (and – in fact – a solid body of standards and bestpractice exists), effective measures to ensure data subject rights are usually not considered. Thisreport intends to improve the understanding of those rights, and provide good practices for theimplementation of mechanisms that allow data subjects to exercise their rights.

ReferencesCSA 2010 Cloud Security Alliance, Domain 12: Guidance for Identity & Access Management V2.1, 2010,

avail at. https://cloudsecurityalliance.org/guidance/csaguide-dom12-v2.10.pdf


EC 2012 European Commission, Proposal for a Regulation of the European Parliament and of the Council on the protection of individuals with regard to the processing of personal data and on the free movement of such data (General Data Protection Regulation), COM(2012) 11 final.

IPL 2014 Center for Information Policy Leadership, The Role of Risk Management in Data Protection, Paper 2 of the Project on Privacy Risk Framework and Risk-based Approach to Privacy, 2014,avail. at. https://www.informationpolicycentre.com/files/Uploads/Documents/Centre/The_Role_of_Risk_Management_in_Data_Protection_FINAL_Paper.PDF

NIST 2010 National Institute or Standards and Technology, Guide to Protecting the Confidentiality of Personally Identifiable Information (PII), NIST Special Publication 800-112, 2010.

NIST 2013 National Institute or Standards and Technology, Security and Privacy Controls for Federal Information Systems and Organizations, NIST Special Publication 800-53, 2013

NIST 2014 National Institute or Standards and Technology, Standards for Security Categorization of Federal Information and Information Systems, Federal Information Processing Standards Publication FIPS PUB 199, 2014

OASIS 2014 Organization for the Advancement of Structured Information Standards, Privacy by Design Documentation for Software Engineers Version 1.0, Committee Specification Draft 01, avail. at. http://docs.oasis-open.org/pbd-se/pbd-se/v1.0/csd01/pbd-se-v1.0-csd01.html

OECD 1980 OECD, Guidelines on the Protection of Privacy and Transborder Flows of Personal Data, 1980.

PBD 2011 Information and Privacy Commissioner of Ontario, Privacy by Design: Strong Privacy Protection – Now, and Well into the Future, A Report on the State of PbD to the 33rd International Conference of Data Protection and Privacy Commissioners, 2011, avail. at. https://www.ipc.on.ca/images/Resources/PbDReport.pdf.


https://www.ipc.on.ca/images/Resources/PbDReport.pdf

https://www.informationpolicycentre.com/files/Uploads/Documents/Centre/The_Role_of_Risk_Management_in_Data_Protection_FINAL_Paper.PDF

https://www.informationpolicycentre.com/files/Uploads/Documents/Centre/The_Role_of_Risk_Management_in_Data_Protection_FINAL_Paper.PDF

https://cloudsecurityalliance.org/guidance/csaguide-dom12-v2.10.pdf