#  Executive Summary

The results and data of the BPR4GDPR project that are necessary for the
project’s purpose will be openly published to communicate and spread the
knowledge to all interested communities and stakeholders. In this context, the
privacy by default principle will be considered. Therefore, only data that is
needed for the validation of presented results in scientific publications will
be included within the Data Management Plan (DMP). All the other data that
will be generated within the project can be published on a voluntary basis as
stated in the DMP. Published results generate wider interest towards the
improvements achieved by the project in order to facilitate and potentiate
exploitation opportunities. The goal of this deliverable is listing
publishable results and research data and investigating the appropriate
methodologies and open repositories for data management and dissemination. The
BPR4GDPR’s partners aim to offer as much information as possible generated by
the project through open access as long as it does not adversely affect its
protection or use, and subject to legitimate interests and applicable laws.
Such information include scientific publications issued by the BPR4GDPR
consortium, white papers published, open source code generated, anonymous
interview results, or mock-up datasets used for gathering customer feedback.

As it can be seen in Figure 1, different research actions lead to different
ways of dissemination or exploitation. In case of dissemination and sharing,
there are two different types of project result publishing. On the one hand,
there are publications that can have gold or green open access, or on the
other hand depositing of research data via access and use that can be either
restricted or free of charge. It is tried to make those publications and
research data available as far as possible. However, not all
collected/generated data can be published openly, as it may contain
confidential personal and business information or other information that
deserves specific protection under applicable laws or applicable contractual
agreements between the interested parties. This kind of data must be
identified and protected accordingly.

**Figure 1: Open access strategy for publications and research data**

#  Introduction

##  Purpose of the Document

For a good Data Management, each project in the EC's Horizon 2020 program has
to define what kind of results will be generated or collected during the
project's runtime, as well as when and how the results will be published
openly. Consequently, the following DMP regards the whole data management
lifecycle of the Horizon 2020 project “BPR4GDPR”. For all results generated or
collected during BPR4GDPR, a description is provided including the purpose of
the document, the standards and metadata used for storage and the facility
used for sharing the data, based on the EC template recommended. In detail,
the purpose of the DMP is to give information about:

(European Commission, 2016, p. 2)

  * the handling of research data during & after the project, 

  

  * what data will be collected, processed or generated, 

  

  * which methodology & standards will be applied,  whether data will be shared/made open access and how,  how data will be curated & preserved. 

  

In this way, data will become “FAIR” (findable, accessible, interoperable,
reusable). Furthermore, data privacy within the project and the compliance
with the General Data Protection Regulation (Regulation EU 2016/679 – "GDPR")
will be set out. Finally, the result should be a data policy that leads the
consortium partners in executing a good data management and additionally
considers resources and budgetary planning for data management.

This document is an initial version, due in project month 6. The DMP will be
updated on a regular basis in the project months 12, 24 and 36 (see
Deliverables D1.6 to D1.8 – M12, M24 and M36 Data Management Plan). It does
not describe how the results are exploited, which is part of the deliverables
D7.2 to D7.4 (Initial, intermediate and final dissemination, standardisation
and exploitation plan). Instead, the updated DMP will contain information to
new datasets that have been collected or generated in the meantime as well as
changed consortium policies and other external factors. Nevertheless, the
future versions will take into account that there is a consistency with the
exploitation actions as well as with the IPR requirements.

In particular, BPR4GDPR’s DMP will be useful for the project consortium itself
as well as for the European Commission. Furthermore, general public can
benefit from the document.

##  Project Description

The objectives for BPR4GDPR are the following:

  * A **reference compliance framework** that is reflecting the associated provisions and requirements for GDPR to facilitate compliance for organisations. This framework will serve as the codification of legislation. 

  

  * **Sophisticated security and privacy policies** through a comprehensive, rule-based framework capturing complex concepts in accordance with the data protection legislation and stakeholder needs and requirements. 

  

  * **By design privacy-aware process models** and underlying operations by provision of modelling technologies and tools that analyse tasks, interactions, control and data flows for natively compliant processes and workflow applications with security and privacy provisions and requirements. 

  

  * **Compliance-driven process re-engineering** through a set of mechanisms for automating the respective procedures regarding all phases of processes’ lifecycle and resulting in compliant-by-design processes. 

  

  * A configurable **compliance toolkit** that fits the needs of various organisations being subject to GDPR compliance and that incorporates functionalities for managing the interaction with the data subject and enforcing respective rights. 

  

  * The implementation of inherently offered **Compliance-as-a-Service (CaaS)** at the Cloud infrastructures of BPR4GDPR partners to achieve compliance at low cost to SMEs. 

  

  * Deployment of the BPR4GDPR technology and overall framework, corresponding to **comprehensive trials** that involve software companies, service providers and carefully selected stakeholders to assess the BPR4GDPR solution, to validate different deployment models and to define a market penetration roadmap. 

  

  * Profound **impact creation** in European research and economy, especially as regards the areas of data protection, security, BPM, software services, cloud computing, etc. 

  

Along with these above-mentioned objectives, the BPR4GDPR data that needs to
be handled and that is described within the DMP is associated with project
results as Regulation-driven policy framework, Compliancedriven process re-
engineering, Compliance toolkit, Process discovery and mining enabling
traceability and adaptability, Compliance-as-a-Service (CaaS) and Impact
creation – holistic innovation approach resulting in sustainable business
models.

##  Terminology

**Open Access** : Open access means unrestricted access to research results.
Often the term open access is used for naming free online access to peer-
reviewed publications. Open access is expected to enable others to: a) Build
on top of existing research results,

  2. Avoid redundancy, 

  

  3. Participate in open innovation, and 

  

  4. Read about the results of a project or inform citizens. 

  

  

All major publishers in computer science – like ACM, IEEE, Elsevier, or
Springer - participate in the idea of open access. Both green or gold open
access levels are promoted. Green open access means that authors eventually
are going to publish their accepted, peer-reviewed articles themselves, e.g.
by deposing it to their own institutional repositories or digital archives.
Gold open access means that a publisher is paid (e.g. by the authors) to
provide immediate access on the publishers website and without charging any
further fees to the readers.

**Open Research Data** : Open research data is related to the long-term
deposit of underlying or linked research data needed to validate the results
presented in publications. Following the idea of open access, all open
research data needs to be openly available, usually meaning online
availability. In addition, standardized data formats and metadata has to be
used to store and structure the data. Open research data is expected to enable
others to:

  1. Understand and reconstruct scientific conclusions, and 

  

  2. To build on top of existing research data. 

  

  

**Metadata** : Metadata defines information about the features of other data.
Usually metadata is used to structure larger sets of data in a descriptive
way. Typical metadata refers to names, locations, dates, storage data type,
and relations to other datasets. Metadata is very important when it comes to
index and search larger data sets for a specific kind of information.
Sometimes metadata can be retrieved automatically from a dataset, but often it
is also needed some manual classification. The well-known tags in
MP3-recordings are a good example of why metadata is necessary to find a
specific kind of genre or composer in a larger number of songs.

**FAIR Data:** To ensure a sustainable usage of Open Research Data, the
principle of “FAIR Data” should be met by the data in question as well as by
the underlying data infrastructure. Therefore, FAIR data should be **F**
indable, **A** ccessible, **I** nteroperable and **R** eusable. In detail,
this means:

Findable:

  * Discoverability of data (standard identification mechanisms, naming conventions, search keywords)  Approach for clear versioning 

  

  * Metadata provision and possible used standards for metadata creation 

  

Accessible:

  * Description of openly available and closed data (with reasons) and the process to make them available 

  

  * Definition of methods or software tools needed to access data 

  

  * Specification where data, associated metadata, documentation and code are deposited 

  

Interoperable:

  * Assessment of interoperability of project data (What data and metadata vocabularies, standards or methodologies?) 

  

  * Existence of standard vocabulary or commonly used ontologies for all data types in the data set 

  

Reusable:

  * Licencing of data for maximum reuse 

  

  * When will data be made available for reuse (why/for what is data embargo needed) 

  

  * Are Produced/used data reusable by third parties after project end? Why restricted? 

  

  * Data quality assurance processes 

  

  * Specification of time length for which data will be reusable 

  

##  Structure of the Document

The rest of the document is structured into four further sections.

Section 3 handles the general structuring of the data within the project,
meaning data set reference and naming as well as the usage of metadata
standards that will give the framework for the metadata template.

Section 4 defines the strategy that will be applied to all results collected
or generated during BPR4GDPR for sharing and preservation and contains a
summary of all publishing platforms to be used by the BPR4GDPR consortium.
Included is a process that defines if a result has to be published or not.
Moreover, the security of data sharing and data preservation will be taken
into consideration.

Section 5 considers costs that go along with the data management, usage of
sharing and preservation platforms and availability of open access.
Furthermore, responsibilities for data management actions including security
and quality issues will be defined.

Section 6 lists publications and other public related data(sets) that are
already or may be generated or collected during BPR4GDPR. For each result, a
short description, the chosen way of open access, and a longterm storage
solution are specified according to the EC's data management guidelines
(European Commission, 2016) and by using the metadata template presented in
Section 3.

#  Data Structure

A first step to make the data in the BPR4GDPR project “FAIR” is to give the
data some structure. This means a consistent naming of the data that makes
them easier findable and that includes clear versioning and the commitment to
metadata standards for better tracing of existing and future data. Through
standardized information within a metadata template, like for example the data
set type, discoverability of the data can be increased. Moreover, it is easier
for applications to consume and process the metadata for assessing the value
of the data and for further usage.

The data title itself should also include some metadata, which help to
increase data handling and working efficiency. Possible metadata components
for the data naming are the title, version number, prefixes, linkages to work
packages or tasks, the dataset topic, creation date or the modification date.
In the case of BPR4GDPR, especially the dataset date and a versioning number
should be used for a higher transparency of data modifications as well as the
linkage to the work package for a thematic classification of the data. The
usage of these metadata components results in the following data naming:

_“BPR4GDPR_WP-No._Version-Date_Title_Deliverable-No._Version number”_

However, the metadata component “Deliverable-No.” is just optional due to the
fact that not each dataset can be directly linked to a specific deliverable.
An example for such a dataset naming could be the following:

_BPR4GDPR_WP1.1_20180920_M6 Data Management Plan_D1.5_V3_

In this context, a metadata template can be generated including information
that goes beyond the metadata that can be deduced from the dataset naming.
Apart from standard information as title, creation date or language, this
template comprises further aspects, like the data origin, expected size of the
dataset, a general description of the data, reference to publications,
keywords belonging to the data or target group. This metadata template shall
be additionally saved within the repository. The following Table 1 shows such
a template to describe data that will be produced in the context of BPR4GDPR.

**Table 1: BPR4GDPR Metadata Template**  
  
<table>  
<tr>  
<th>

**Initial Dataset Template**

</th> </tr>  
<tr>  
<td>

**Dataset reference name**

</td>  
<td>

Identifier for the data set to be produced using the above described naming
convention.

</td> </tr>  
<tr>  
<td>

**Dataset title**

</td>  
<td>

The easy searchable and findable title of the dataset.

</td> </tr>  
<tr>  
<td>

**Dataset description**

</td>  
<td>

Description of the data that will be generated or collected, its origin (in
case it is collected), nature and scale and to whom it could be useful, and
whether it underpins a scientific publication. Information on the existences
(or not) of similar data and the possibilities for integration and reuse.

</td> </tr>  
<tr>  
<td>

**Standards and metadata**

</td>  
<td>

Reference to existing suitable standards of the discipline. If these do not
exist, an outline on how and what metadata will be created.

</td> </tr>  
<tr>  
<td>

**Keywords**

</td>  
<td>

List of keywords that are associated to the dataset.

</td> </tr>  
<tr>  
<td>

**Data sharing**

</td>  
<td>

Description of how data will be shared, including access procedures, embargo
periods (if any), outlines of technical mechanisms for dissemination and
necessary software and other tools for enabling reuse, and definition of
whether access will be widely open or restricted to specific groups.
Identification of the repository

</td> </tr>  
<tr>  
<td>

</td>  
<td>

where data will be stored, if already existing and identified, indicating in
particular the type of repository (institutional, standard repository for the
discipline, etc.).

</td> </tr>  
<tr>  
<td>

**Archiving and preservation**

**(including storage and backup)**

</td>  
<td>

Description of the procedure that will be put in place for long-term
preservation of the data. Indication of how long the data should be preserved,
what is its approximated end, volume, what the associated costs are and how
these are planned to be covered.

</td> </tr>  
<tr>  
<td>

**Additional Dataset explanation**

</td> </tr>  
<tr>  
<td>

**Discoverable**

</td>  
<td>

Are the data and associated software produced and / or used in the project
discoverable (and readily located), identifiable by means of a standards
identification mechanism? (e.g. Digital Object Identifier)

</td> </tr>  
<tr>  
<td>

**Accessible**

</td>  
<td>

Are the data and associated software produced and / or used in BPR4GDPR
accessible and in what modalities, scope, licenses? (e.g. licencing framework
for research and education, embargo periods, commercial exploitation, etc.)

</td> </tr>  
<tr>  
<td>

**Assessable and intelligible**

</td>  
<td>

Are the data and associated software produced and / or used in the project
assessable for and intelligible to third parties in contexts such as
scientific scrutiny and peer review? (e.g. Are the minimal datasets handled
together with scientific papers for the purpose of peer review? Are data
provided in a way that judgments can be made about their reliability and the
competence of those who created them?)

</td> </tr>  
<tr>  
<td>

**Usage beyond the original purpose for which it was collected**

</td>  
<td>

Are the data and associated software produced and / or used in BPR4GDPR
useable by third parties even long time after the collection of the data?
(e.g. Is the data safely stored in certified repositories for long term
preservation and curation? Is it stored together with the minimum software,
metadata and documentation to make it useful? Is the data useful for the wider
public needs and usable of the likely purpose of non-specialists?)

</td> </tr>  
<tr>  
<td>

**Interoperable to specific quality standards**

</td>  
<td>

Are the data and associated software produced and / or used in the project
interoperable allowing data exchange between researchers, institutions,
organisations, countries, etc.? (e.g. adhering to standards for data
annotation, data exchange, compliant with available software applications, and
allowing recombinations with different datasets from different origins)

</td> </tr> </table>

As recommended by the European Commission, also the usage of metadata
standards should be regarded. Such a metadata standard is a document that
defines how metadata will be tagged, used, managed, formatted, structured or
transmitted. Besides standardized data formats as CSV, PDF and DOC/DOCX for
texts and tables, PPT for presentations, JPEG, PNG and GIF for images, or the
XES-format for event logs that are used in BPR4GDPR to exchange event-driven
data in a unified and extensible manner, also other (meta-)data standards are
considered. For example, the RDF (Resource Description Framework) vocabulary
is a metadata standard, which can be used in case of BPR4GDPR. At first the
RDF has only been designed as a metadata standard by the World Wide Web
Consortium (W3C), however by now it is a fundamental element of the semantic
web and to formulate logical statements. Such an RDF-based vocabulary is DCAT
(data catalog vocabulary). This standard has been generated in order to
optimize the interoperability on the web along several data catalogs, where
data are described in. The DCAT vocabulary is listed in the following and can
be used for the dataset description:

  * dct:identifier to provide the dataset’s unique identifier 

  

  * dct:title to give the dataset a specific title 

  

  * dct:theme to provide the main theme(s) of the dataset 

  

  * dct:descripton to describe the dataset with free-text 

  

  * dct:issued to provide the date of the issuance/publication of the dataset 

  

  * dct:modified to provide the date of the latest dataset modification/change/update 

  

  * dct:language to mention the dataset language 

  

  * dct:publisher to state the responsible entity that published the dataset/made it available 

  

  * dcat:keyword to provide several keywords that describe the dataset 

  

  * dcat:temporal to state the dataset’s temporal period 

  

  * dcat:distribution to link the dataset with all available distributions 

  

#  Data Management Strategy

The BPR4GDPR Data Management Strategy consists of a publishing process to
divide public from non-public data and strategies for data sharing as well as
archiving and preservation that together provide long-term open access to all
publishable, generated or collected results of the project. The implementation
of the project complies with laws at a national and EU level and especially
with GDPR in relation to the protection of personal data of individuals. More
specifically, there will be no cases where personal information or sensitive
information of internet users or other involved persons is collected (IP
addresses, email addresses or other personal information) or processed. For
the whole duration of the project, from the beginning to its end, the Data
Protection Manager (DPM – Mrs. Francesca Gaudino (BAK)) will carefully examine
the legality of the activities and the tools (including platforms) that will
be produced for not violating the personal data of internet users or other
involved persons. In the potential future case where the BPR4GDPR consortium
will collect, record, store or process any personal information, it will be
ensured that this will be done on a basis of respecting citizens’ rights,
preventing their identification and keeping their anonymization. The
publishing process as well as the data sharing, archiving and preservation
strategies are described in the following subsections. Furthermore, it will be
explained how data security will be handled within the process and strategies.

Through the whole data management strategy the consistency with the project’s
exploitation actions and IPR requirements, as well as compliance with WP8
Ethics requirements will be guaranteed. As set in the DoW of BPR4GDPR, the
project’s partners ensure to share and disseminate their own knowledge as far
as it does not adversely affect its protection or use. Furthermore, the IPR
consortium agreement takes into consideration a workshop after the project end
in order to provide a list of all generated results with a separate decision
of joint or single ownership for each result. Eventually, first suggestions
for usable sharing platform have been mentioned as the open access
infrastructure for Research in Europe “OpenAIRE”, the scholarly open access
repository arXiv, BPM Center or the project portal itself.

##  Publishing Process

A simple and deterministic process has been defined that decides if a result
in BPR4GDPR has to be published or not. The term “result” is used for all kind
of artefacts generated during BPR4GDPR like white papers, scientific
publications, and anonymous usage data. By following this process, each result
is either classified public or nonpublic. Public means that the result must be
published under the open access policy. Non-public means that it must not be
published.

For each result generated or collected during BPR4GDPR runtime, the following
questions have to be answered to classify it:

  1. _Does a result provide significant value to others or is it necessary to understand a scientific conclusion?_

  

  

If this question is answered with yes, then the result will be classified as
public. If this question is answered with no, the result will be classified as
non-public. Such a result could be code that is very specific to BPR4GDPR
platform (e.g. a database initialization) which is usually of no scientific
interest to anyone, nor add any significant contribution.

  2. _Does a result include personal information that is not the author's name?_

  

  

If this question is answered with yes, the result will be classified as non-
public. Personal information beyond the name must be removed if the result
should be published. This also bares witness on the repetitive nature of the
publishing process, where results which are deemed in the beginning as non-
publishable can become publishable once privacy-related information or other
information subject to confidentiality obligations is removed from them.

  3. _Does a result allow the identification of individuals even without the name?_

  

  

If this question is answered with yes, the result is classified as non-public.
Sometimes data inference can be used to superimpose different user data and
reveal indirectly a single user's identity. As such, in order to make a result
publishable, the included information must be reduced to a level where single
individuals cannot be identified. This can be performed by using established
anonymisation techniques to conceal a single user's identity, e.g.,
abstraction, dummy users, or non-intersecting features.

  4. _Does a result include business or trade secrets of one or more partners of BPR4GDPR?_

  

  

If this question is answered with yes, the result is classified as non-public,
except if the opposite is explicitly stated by the involved partners. Business
or trade secrets need to be removed in accordance to all partners'
requirements before it can be published.

  5. _Does a result name technologies that are part of an ongoing, project-related patent application?_

  

  

If this question is answered with yes, then the result is classified as non-
public. Of course, results can be published after patent has been filed.

  6. _Can a result be abused for a purpose that is undesired by society in general or contradict with societal norms and BPR4GDPR’s ethics?_

  

  

If this question is answered with yes, the result is classified as non-public.
_7\. Does a result break national security interests for any project partner?_

If this question is answered with yes, the result is classified as non-public.

##  Data Sharing

Consequently, with the publishing process all the data that cannot be
published due to specific reasons like ethical or privacy- and/or security-
related issues have been identified. All the other data that have been
classified as publishable/public will be considered in the following sections
of the deliverable.

For sharing the data among the consortium partners, a Nextcloud repository has
been set up. The repository has been selected since it allows a secure and
facilitated sharing of documents between the partners via web interface and on
several devices. The Nextcloud is extensible for further plugins and
applications and is hosted by the consortium partner Università di Roma “Tor
Vergata”. Access to the repository is only granted to consortium members.
Nextcloud includes the assignment of rights, like the right of re-sharing,
creation, change, deletion and a settable expiration date.

For public sharing in BPR4GDPR, the consortium partners use several platforms
to publish our results openly and to provide them for re-usage. All the
consortium partners should make their generated results as quickly as possible
available unless there have been reasons identified along the publishing
process (see section 4.1), that classify them as non-public. The following
list presents a closer selection of platforms that should be considered for
data sharing and describes their concepts for publishing, storage and backup.

After having selected all relevant datasets and results that can be published
and that have not been identified as “non-public”, the datasets/documents
should be archived in a selected repository upon acceptance for public. In
such manner, either a publisher’s final version of a paper or the final
manuscript that has been accepted for publication, both including peer review
modifications, should be deposited. The selected repository depends on the
dataset type. While some repository platforms only integrate publications,
others also accept datasets, no matter if the dataset is linked to a
publication or not.

**4.2.1 Data Sharing Platforms Project Website/Project Portal:**

The partners in the project consortium decided to setup a project-related
website. This website describes the mission, the objectives, the benefits and
impact, as well as the general approach of BPR4GDPR and its development
status. Moreover, all interesting news considering announcements, conferences
and events or other related information are disseminated on a regular basis.
Later in the project, the developed BPR4GDPR policy framework and compliance
toolkit will be announced. A dedicated area for downloads is made available in
order to publish reports and white papers as well as scientific publications.
All documents are published using the portable document format (PDF). All
downloads are enriched by using simple metadata information, such as the title
and the type of the document. The website is hosted by partner Eindhoven
University of Technology. All webpage-related data is backed on a regular
basis. All information on the project website can be accessed without creating
an account. Web-Link:  _http://www.bpr4gdpr.eu/_

**OpenAIRE:**

OpenAIRE is an Open Access infrastructure for Research in Europe that is
recommended by the European Commission and that allows access to research
results that have been funded by FP7 and ERC resources. OpenAIRE allows to
monitor, identify, deposit and access research outcomes throughout Europe and
supports the potential of international open access repositories
collaboration. Through such workflows that go beyond repository content,
interoperability across several repositories is achieved.

The project started in December 2009 and aimed to support the implementation
of Open Access in Europe. For the development of the infrastructure, state-of-
the-art software services that have been generated within the DRIVER and
DRIVER-II projects as well as repository software by CERN have been used.
Especially research data on areas like health, energy, environment or ICT are
deposited via OpenAIRE. Through this platform, researchers and universities
that are involved in a Horizon 2020 project are supported in fulfilling the
EC’s open access policy. Web-Link:  _http://www.openaire.eu_

**Zenodo:**

Zenodo is a research data archive/online repository which helps researchers to
share research results in a wide variety of formats for all fields of science.
It was created through EC's OpenAIRE+ project and is now hosted at CERN using
one of Europe's most reliably hardware infrastructures. Data is backed nightly
and replicated to different locations. Zenodo not only supports the
publication of scientific papers or white papers, but also the publication of
any structured research data (e.g., using XML). Zenodo provides a connector to
GitHub that supports open collaboration for source code and versioning for all
kinds of data. All uploaded results are structured by using metadata, like for
example the contributors’ names, keywords, date, location, kind of document,
license and others. All metadata is licensed under CC0 license (Creative
Commons ‘No Rights Reserved’). The property rights or ownership of a result
does not change by uploading it to Zenodo. Web-Link:  _http://zenodo.org_
**arXiv:**

The high-automated electronic archive “arXiv” is another scholarly open access
repository for preprints that is hosted by the Cornell University Library.
This distribution server concentrates on research articles that are rather
located in technical areas as mathematics, statistics, physics, computer
science or electrical engineering. Nontechnical information should not be
shared over this platform. Through an arXiv Scientific Advisory Board and an
arXiv Member Advisory Board that consists of scientists and the scientific
cultures it serves, the repository is guided and maintained. Further subject
specialists check and review the publications in accordance to their relevance
and their compliance to standards. Moreover, an endorsement by an already
renowned author is necessary to deposit any articles on arXiv. For publishing
the article, data formats as PDF or LaTeX are possible. Web-Link:
_http://arxiv.org_ **GitHub:**

GitHub is a well-established online repository, which supports distributed
source code development, management and revision control. It is primarily used
for source code data. It enables world-wide collaboration between developers
and provides also some facilities to work on documentation and to track
issues. The platform uses metadata like contributors’ nicknames, keywords,
time, and data file types to structure the projects and their results. The
terms of service state that no intellectual property rights are claimed by the
GitHub Inc. over provided material. For textual metadata items, English is
preferred. The service is hosted by GitHub Inc. in the United States. GitHub
uses a rented Rackspace hardware infrastructure where data is backed up
continuously to different locations.

Web-Link:  _https://github.com/_

**BPM Center:**

The BPM Center is a center founded in 2004 at Eindhoven University of
Technology in collaboration with Queensland University of Technology in
Australia explicitly for research in the Business Process Management (BPM)
field. The virtual research center handles business processes along all the
lifecycle that covers phases like the process modelling , process monitoring
or process mining. Especially in case of BPR4GDPR that handles Business
Process Re-engineering in accordance with GDPR and due to the fact that the
repository derives from the partner TU/e, this research center plays an
interesting role.

Another opportunity of the Eindhoven University of Technology to share data
and maximise the value for others by sharing knowledge is through the 4TU
programme. The four Universities of technology in the Netherlands set up this
programme with the aim to exploit knowledge in the technology as far as
possible. Particularly, the 4TU Centre for Research Data is the most
prestigious technical and scientific data archive in the Netherlands.

Web-Links:  _http://bpmcenter.org/_ _https://www.4tu.nl/en/_

All public results generated or collected during the project lifetime will be
uploaded to one of these above mentioned repositories for long-term storage
and open access. Thereby, the choice of an adequate repository depends on the
dataset type. Source-code components will be differently published as
publications. Furthermore, the sharing platform will be selected depending on
the target group that could be interested in the data.

###  Artefact Types

This section just attempts to enumerate specific datasets, software and
research items (from which publications can be produced) and whether all these
artefacts can be publishable or not according to what means. Each type of
artefact requires a specific kind of sharing platform. The artefacts are
deduced from the expected results referring to the BPR4GDPR proposal.

**Table 2: Project Artefacts**  
  
<table>  
<tr>  
<th>

**Artefact Type**

</th>  
<th>

**Artefact**

</th>  
<th>

**Possible Publication Means**

</th> </tr>  
<tr>  
<td>

**Research Item**

</td>  
<td>

Regulation-driven policy framework

</td>  
<td>

OpenAIRE, Zenodo, arXiv, project website

</td> </tr>  
<tr>  
<td>

**Research Item**

</td>  
<td>

Impact creation – holistic innovation approach resulting in sustainable
business models

</td>  
<td>

OpenAIRE, Zenodo, arXiv, project website

</td> </tr>  
<tr>  
<td>

**Software**

</td>  
<td>

Compliance-driven process reengineering

</td>  
<td>

OpenAIRE, Zenodo, GitHub, BPM Center

</td> </tr>  
<tr>  
<td>

**Software**

</td>  
<td>

Compliance toolkit

</td>  
<td>

OpenAIRE, Zenodo, GitHub

</td> </tr>  
<tr>  
<td>

**Software**

</td>  
<td>

Process discovery and mining enabling traceability and adaptability

</td>  
<td>

OpenAIRE, Zenodo, GitHub, BPM Center

</td> </tr>  
<tr>  
<td>

**Software**

</td>  
<td>

Compliance-as-a-Service (CaaS)

</td>  
<td>

OpenAIRE, Zenodo, GitHub

</td> </tr>  
<tr>  
<td>

**Dataset**

</td>  
<td>

Anonymous usage statistics

</td>  
<td>

OpenAIRE, Zenodo, 4TU

</td> </tr>  
<tr>  
<td>

**Dataset**

</td>  
<td>

UseCase data

</td>  
<td>

Non-publishable

</td> </tr> </table>

##  Archiving and Preservation

Within the data management plan, also the long-term preservation of the data,
that goes beyond the project lifetime, has to be considered. For these
preservation procedures, the duration of data preservation, end volume of the
data and preservation mediums will be regarded.

The preservation of BPR4GDPR data will succeed via institutional and free
usable platforms. Especially, Zenodo and 4TU seem to be adequate solutions for
archiving as these platforms do not create any additional, further costs to
store the data on the repository. Through linked metadata templates the data
can be made more findable and accessible as well as through a Digital Object
Identifier (DOI) that is matched to each upload. On top of that, it
constitutes a repository for a variety of topics that is recommended by the
European Commission, based on OpenAIRE and that accepts all kinds of dataset
types. But also OpenAIRE itself represents a similar attractive repository for
archiving that is equally proposed as an Open Access repository by the
European Commission.

By using at least one of the described repositories, the assumed preservation
time will be set to 5 years to guarantee a long access and the re-usability of
the project data. For this purpose, it will be strived to provide data of
maximal quality and validity to ensure data usability during this preservation
time. Therefore, datasets will be updated in case of adjusted data available.

However, the archiving and preservation strategy could possibly be altered and
updated during the project lifetime since further advantages or disadvantages
of several repositories could be identified during this time, which could lead
to a necessary adjustment of the preservation intentions. Possible amendments
will be documented in a later, updated version of the data management plan
(see deliverables D1.6 to D1.8 – M12, M24 and M36 Data Management Plan).

##  Data Security

Data security is considered during the management of data in accordance to the
GDPR regulations and applicable laws on data protection and data security. For
this reason, the publishing process in Section 4.1 deals with the separation
of publishable and non-public data and results that arise within BPR4GDPR. As
a result, only data that are necessary for the purpose of the project will be
regarded, in accordance with the privacy by default principle.

In case of personal identification data, that are said to be of real
scientific interest, specific measures will be deployed in order to anonymize
data, such as the use of aggregated and statistic data, so that personal
identification data will be transformed in information that cannot identify an
individual anymore, not even indirectly.

As already mentioned in Section 4.2, the data handling among the consortium
partners takes place via Nextcloud. Data security on this repository will be
ensured by hosting the data at a partner’s private server (Università di Roma
“Tor Vergata”) and by using a platform, that covers several security issues
and that is compliant with GDPR itself. This is assured by the reliance to the
EU authentication platform and security protocols for data sharing, strict
policies for granting and revoking platform access (access to the repository
is only granted to consortium members), and the recording of user identity
during data access, download, and upload. In this way, Nextcloud enables the
project to assign rights to specific data (re-sharing, creation, change,
deletion or a settable expiration date). On top of that, Nextcloud is
extensible for further security plugins.

Also the used repositories for public datasets and results comply with
security and privacy regulations. For example, data on the Zenodo platform are
stored on the same infrastructure as the research data of CERN, that is hosted
on a reliable hardware infrastructure in Europe. Furthermore, data on those
repositories is backed up on a regular basis.

#  Costs and Responsibilities

To manage the data within BPR4GDPR also the costs necessary for making
research data “FAIR” (see Section 2.3) have to be estimated and taken into
consideration. These costs arise due to the required measures for integrating
data into a platform and storing data during the project lifetime and
afterwards. However, costs associated with open access of research data within
any Horizon 2020 project can be handled as eligible costs.

Nonetheless, the selected repositories for data sharing and preservation are
on the one hand free for researchers to deposit their publications (see
Zenodo, arXiv etc.) and on the other hand the stored data can be freely
accessed by public. For example, arXiv only offers a special membership
programme for arXiv's heaviest institutional users. In contrast, GitHub
provides paid as well as free service plans. Free service plans can have any
number of public, open-access repositories with unlimited collaborators.
Private, non-public repositories require a paid service plan. Many open-source
projects use GitHub to share their results for free. Beyond that, no further
costs are at this stage anticipated relating to data management during and
after the project runtime. In case of any alteration, further emerging costs
will be outlined in an updated data management plan (D1.6 to D1.8 – M12, M24
and M36 Data Management Plan).

The compliance of the project’s data management with the described security
and cost related issues will be handled by the project’s Data Protection
Manager. Especially the assurance that data collection and processing within
the project align to EU and national legislation are a main part of this role.
This means security assessments and reporting of potential security threats.
In the case of BPR4GDPR Mrs. Francesca Gaudino (BAK) will be responsible for
this task.

However, for the data preparation as well as for the relevance, quality and
currency of the data, the respective data owners are responsible. To this end,
data preparation considers the data anonymization and data processing to make
these data ready for publishing. On top of that, data owners have to ensure
the compliance of uploaded data with the conditions that have been defined in
the project’s data management plan. Furthermore, also the completion of the
specific metadata templates for any dataset is the responsibility of the data
owners.

In turn, the BPR4GDPR partner that is hosting the Nextcloud repository for the
project’s internal data exchange (Università di Roma) is responsible for the
maintenance of this repository and its components as well as for the user
group management.

#  Project Results

In this section the metadata template introduced in Section 3, that describes
the data within BPR4GDPR, will be used for the current project results. Every
use case will provide such a template to share the gained knowledge as far as
feasible and in relation to the described publishing process and its questions
in Section 4.1. This will occur during the project duration, whereby the data
management plan will be regularly updated in this time (see deliverables D1.6
to D1.8 – M12, M24 and M36 Data Management Plan).