#  1\. INTRODUCTION

This document presents the Data Management Plan (DMP) describing how the data
generated within the project are processed and preserved during EPICAs
lifetime. As the project will control, handle and process sensitive data from
different sources, the need for appropriate data management is highly
important.

The research data management procedures will be further described in future
releases of the DMP, as the project develop, and the data collection methods
are established and adjusted according to EPICAs on-going operations and the
project maturity.

This DMP is based on the H2020 Programme Guidelines on FAIR Data Management in
Horizon 2020. The goal is that the DMP will ensure that project generated data
is findable, accessible, interoperable and reusable, also allowing project
data to be generated, stored and managed during the complete project lifetime,
subject to changes in consortium policies and methodology.

The DMP is interconnected to deliverable D1.2 - “Ethics, Data Protection and
Privacy Management Plan”, especially regarding the procedures and policies of
collecting and protecting personal and sensitive data. In this regard GDPR
compliance is critical, and self-declarations of compliance from all partners
are referenced in the Appendixes of the DMP.

This document is further based on the terms and conditions established in the
Grant Agreement and its Annexes, as well as the applicable articles in the
Consortium Agreement.

The DMP is a deliverable which is intended to be used by all the project
partners, to ensure quality assurance of project processes and outputs and
prevent possible deviations from the project work plan as described in the
EPICA DOA.

The DMP also provides an analysis of the main elements of the data management
conducted within the EPICA project framework – and when in compliance -
ensures coherent management of the project data generated amongst and by the
consortium during the project.

_**Figure 1:** The data life cycle analyzed (University of Virginia Library,
Research Data Services) _

2\. DATASET AND STORAGE DESCRIPTION

The purpose of the collected and generated data is to use them for carrying
out the tasks as described in DOA, as well as to be able to validate and
assess the EPICA ePortfolio and relevant components.

The data can be divided into personal and anonymized data. At this stage of
the project, it is not yet exhaustively known which formats the data will
have, but until now, the following formats of data has been utilized:

  1. .docx and equivalent 

  

  2. .pdf and equivalent 

  

  3. .jpeg and equivalent 

  

  4. .xls/xlsx and equivalent 

  

  5. .csv and equivalent 

  

  6. handwritten forms 

  

  7. geo-positioned data 

  

  8. business cards in filing cabinets and/or rolodexes 

  

  9. voice recordings (digital format) 

  

  

Furthermore, the participants will have to fill out surveys via online tools
such as QuestBack, SurveyMonkey and Google Forms and the answers will be
another data source for the researcher within the project.

Data from the pilots is furthermore being reused in order to optimize the
final version accordingly.

The data will be generated and/or provided by the participants, consortium and
from partner universities staff, and will be stored on a specially designated
Google Shared Drive (a restricted database with access log) organized by
folders – where the project coordinator controls the access.

In addition, the consortium members are storing working documents on their
institution’s databases and IT-services – as well as on their own desktops in
the interim.

All EPICA project partners have identified the datasets utilized so far – and
envisioned utilized in the future. The list is provided below, further to be
elaborated on in the following DMP revisions.  
  
<table>  
<tr>  
<th>

**#**

</th>  
<th>

**Aggregate Dataset Name**

</th>  
<th>

**Responsible Partner**

</th>  
<th>

**Related WP**

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

1

</td>  
<td>

Newsletter Subscribers List

</td>  
<td>

ICWE + relevant processor

</td>  
<td>

WP3

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

2

</td>  
<td>

Participant Surveys

</td>  
<td>

OUC + relevant processor

</td>  
<td>

WP4, WP6

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

3

</td>  
<td>

Pedagogical Requirements

</td>  
<td>

OUC + relevant processor

</td>  
<td>

WP4

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

4

</td>  
<td>

Legal Requirements

</td>  
<td>

AVU, ICDE + relevant processor

</td>  
<td>

WP4

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

5

</td>  
<td>

Technical Requirements

</td>  
<td>

MYD + relevant processor

</td>  
<td>

WP5, WP4

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

6

</td>  
<td>

Business Requirements

</td>  
<td>

MYD, ICDE, AVU

</td>  
<td>

WP2

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

7

</td>  
<td>

Other (Working Documents, other etc.)

</td>  
<td>

All

</td>  
<td>

WP1, WP7

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

The above list in indicative for the data, and categorization of the data,
that the EPICA project will produce. This is subject to alteration, and it
might change in the next versions of the DMP considering project developments.

3\. GENERAL PRINCIPLES CONCERNING IPR & PDP

Project partners have specifically retained Intellectual Property Rights (IPR)
on their technologies and data, on which their economic sustainability relies.
As a legitimate result, the EPICA consortium, and partners individually, must
protect these rights and data and consult the concerned partner(s) before
publishing or disseminating data.

All necessary measures should be taken to prevent unauthorized access to the
data, and all data repositories used by the project is in this regard include
a secure protection of sensitive data.

A holistic security approach is furthermore to be undertaken to protect the
three main pillars of information security:

  1. confidentiality 

  

  2. integrity 

  

  3. availability 

  

  

The security approach will consist of a running assessment of security risks
followed by an impact analysis when necessary. This analysis will be performed
on the personal information and data processed by the proposed system, their
flows and any risk associated to their processing.

For a majority of the data acquisition activities to be carried out in the
project, it is necessary to collect basic personal data (e.g. full name,
contact details, background and more), even though the project will avoid
collecting such data unless deemed necessary – employing anonymization or
pseudo-anonymization methods where possible.

Such data will be protected in compliance with the EU's General Data
Protection Regulation (GDPR) aiming at protecting personal data. National
legislations applicable to the project will also be strictly followed, but the
GDPR framework is considered best-practice for this very purpose until the
project’s research discovers conflicting frameworks in other applicable
jurisdictions. As of the third revisioning of the Data Management Plan, other
relevant jurisdictions in Africa have been mapped (subtask T4.2). In this
process, no evidence of a stricter level of data privacy was identified in
Kenya, Tanzania and Uganda, and as such the GDPR level of data privacy remains
the consortia _modus operandi._

All data collected by the project will be done after giving data subjects full
details on the acquisition to be conducted, the data processing and after
obtaining an active and informed consent through a reliable method of
recording data suitable for future storage.

_**Figure 2:** The three pillars of information security (ISO 27001) _

  4. FAIR D  ATA 

  

  

The consortium is striving to make the project data FAIR as described in the
guidelines, provided by the European Commission and their directorate-general
for Research & Innovation for H2020 programs, and the plan will be
increasingly oriented towards this point in detail in the fourth revision of
the data management plan.

This is also applicable to the continuous developed metadata, which is
recorded in terms of contributor identification and version history.

Certain datasets cannot be shared (or need to be shared under restrictions),
due to for example legal and other contractual reasons. Specific beneficiaries
have conditioned to keep their data closed with reference to the provisions
made in the consortium agreement.

In order to maintain a FAIR management of the data, the consortium will
designate their efforts to ensuring that:

  1. All project outputs and otherwise produced project data is discoverable with relevant and logical metadata in a manner that allows for a lean discovery of the data in question. Search keywords should be added to the metadata where possible/reasonable, and at a minimum contain information about the time of the last edit, the author(s), the topic and institutional affiliation. The file type for text files shall be .pdf, .docx or .gdoc to ensure searchability and indexability, and the language used should be general and easily understandable. 

  

  2. All project data is identifiable locatable by means of a standard identification mechanism. All files shall be named with reference to the deliverable and/or subtask the data is tied to or generated in relation to. All file names should be in English and uniformly marked with the institution responsible for the data (abbreviation). 

  

  3. All documents subject to edits and changes should have clear version numbers, with a change log presenting an overview of the previous versions. Version numbers should start at 0.0, and increase with 0.1 for every version. 

  

  4. All project data shall be made available openly by default, subject to restrictions in the Grant Agreement as well as when data privacy concerns takes precedence. ICDE as the project coordinator acts as the repository for all project generated data, and stores this on the shared storage database. Data is accessible (upon deposition) to other project partners via this platform (Google Shared Drive). Third parties may access subject to PCT approval (acting as an ad-hoc Data Access Committee in these questions), in which ICDE as administrator generates the necessary credentials to access the shared drive. The current solution, where ICDE is the project data repository shall be reviewed by M36. 

  

  5. The repository shall in the legitimate interest of protecting project data ascertain the identity of the person accessing data (access logs) 

  

  6. All data produced in the project should be interoperable, allowing for data exchange and re-use between the partners. To achieve this, only well-known formats should be used when storing data. Data stored in the MS Office file format family is to be sought, along with generally recognized open file formats based on the XML and CSV file structure. 

  

  7. All abbreviations used in the generated project data must be outlined in an annex or preamble to the relevant deliverable or text, in order to limit and map the project specific ontologies or vocabularies 

  

  8. If not in conflict with the Grant Agreement, all produced data shall be under the creative commons license “Attribution (BY) 4.0” to permit the widest re-use possible. The Grant Agreement, and adjacent documents, such as the Consortium Agreement, takes precedence. 

  

  9. Research data not involving protected (CA) background, sideground and foreground shall be made available to third parties as quickly as possible. Especially research eligible for publishing in journals should be sought published, where also notification should be sent to ICWE (dissemination partner). 

  

  10. Quality assurance of the data produced under the project shall be carried out by way of partner validation. When a final draft is ready (text, multimodal etc.), one other partner shall review the data to ensure its quality. In order to cover the costs for this, the reviewing partner must be related to the task and work package the data pertains – so that it may report and claim its costs for the time spent on reviewing and ensuring the quality of the data. 

  

  11. Every partner is responsible for its own data management, but the project coordinator (ICDE) has an overarching responsibility to monitor and implement changes to protocols accordingly. The Legal and Data Protection Officer (LDPO) is the person responsible for following up on observed discrepancies of the plan, or act upon notification received from a consortium partner. If a partner has the knowledge about a breach (himself or others) of the DMP, the LDPO shall be notified immediately. The LDPO/DPO shall keep a breach log logging all incidents concerning deviations from the Data Management Plan. 

  

  12. By month 36 a detailed plan for the long-term preservation of the data shall be developed, where the costs and potential value, who decides and how what data will be kept and for how long will be assessed. 

  

  

Under the scope of EPICAs data management plan, good data management is not a
goal in _itself,_ but rather to be considered as a foundation leading to
knowledge discovery and innovation, and as such the recording, management and
the storage of data and knowledge in this regard enables the reuse by the
community after the data is published and disseminated, subject to the
aforementioned IPR-related and contractual restrictions.

_**Figure 3:** The FAIR Guiding Principles (Wilkinson et al., Scientific Data
2016) _

  5. DATA TRANSFER 

  

  

In order to enable collaboration and exchange of project data and contributory
analysis, data must be transferred crossborder between multiple jurisdiction
and applicable data management regulations.

The EPICA project is in this regard subjected to the GDPR framework – which
also regulates cross-border transfer of certain types of data.

In terms if collaborative efforts, the platform utilized is Google Drive, Docs
and Sheets, as well as certain Microsoft Office online and local services.
These providers are incorporated in the United States, and in combination with
the consortium partners, the data is at any applicable time exchanged between
these identified countries:

  1. Spain 

  

  2. Germany 

  

  3. Norway 

  

  4. Tanzania 

  

  5. Kenya 

  

  6. Uganda 

  

  7. United States 

  

  

Intermediaries like AWS and other ISPs are considered to fall within the “Safe
Harbor”-category, and as such not a party to the transfer and exchange of
data. The legal requirements in TZ, KE and UG was mapped in D4.3 - in which a
preliminary report was made available in May 2019. The report identified no
major barriers for the deployment and implementation of the MYD ePortfolio in
Tanzania, Uganda and Kenya. The national regulatory frameworks for each
country does not have in place regulations that exceeds the General Data
Protection Regulation (GDPR) level of requirements. Regarding intermediary
liability, the framework and subsequent practice seems to be harmonized and in
line with international developments, and the local legal requirements are
found to be either less stringent, or absent entirely.

The United States is furthermore under the Privacy Shield framework, and as
such there are regulations directly governing the legalities of EU/U.S. data
exchange/transfer. For the exchange between African and European based project
partners, the DMP is considered sufficient in order to providing “appropriate
safeguards” as to the protection and privacy policies applied to the data,
with reference to GDPR art. 46 and the preliminary legal requirements report.

_**Figure 4:** Structure of EPICAs data transfer relationships. _

  6. DATA SECURITY 

  

  

Considering that EPICA processes sensitive data, and followingly to ensure
data confidentiality, the following encryption systems is analyzed and
utilized:

_ISO/IEC 18033-2:2006 Information technology -- Security techniques –
Encryption algorithms -- Part 2: Asymmetric ciphers)._

Both data at rest and data in flight will be encrypted using the AES symmetric
cipher while secure key exchanges will be performed using an asymmetrical
cipher of at least 2048 bits in length.

EPICA has an explicit plan on how the consortium will handle data generated or
provided by the participants (below, fig.5.). The figure also illustrates how
different data types are handled and stored with a special emphasis on the
different approaches between anonymized and pseudo-anonymized data samples.
These differences are especially important due to the different ethical
problems these respective data types uphold, as described in the Chapter 2 of
the deliverable

1.2 Ethics, Data Protection and Privacy Management Plan.

Main risks are identified to be project partners, aware or unaware, giving
access or sharing sensitive files with unauthorized persons outside the
project group.

The database in which the project data is stored is furthermore subject to an
access and change log.

_**Figure 5:** EPICA Data Storage Plan _

  7. ETHICAL ASPECTS 

  

  

See the D1.2 Ethics, Data Protection and Privacy Management Plan.

  8. DATA MANAGEMENT PLAN FOR DATASETS 

  

  

This form is to be completed and sent to the Project Data Protection Officer
before the acquisition of data is started – and is to form the basis for the
structure of any project dataset.  
  
<table>  
<tr>  
<th>

**EPICA Dataset Template for Processing of Data**

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

**Data Identification**

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

Dataset description

</td>  
<td>

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

Source

</td>  
<td>

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

**Partners Activities and Responsibilities**

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

Owner of Data

</td>  
<td>

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

Data Collection

</td>  
<td>

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

Data Analysis

</td>  
<td>

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

Data Storage

</td>  
<td>

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

Related WP(s) and Task(s)

</td>  
<td>

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

**Standards**

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

Metadata Information

</td>  
<td>

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

(Estimated) Volume of Data

</td>  
<td>

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

Format Standards

</td>  
<td>

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

**Data Exploitation and Sharing**

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

Data Exploitation (purpose)

</td>  
<td>

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

Data Access Policy

</td>  
<td>

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

Data Sharing Policy

</td>  
<td>

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

Embargo Periods

</td>  
<td>

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

Personal Data

</td>  
<td>

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

Special Personal Data

</td>  
<td>

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

**Archiving and preservation (including storage and backup)**

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

Duration of Data Storage

</td>  
<td>

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

Location of Data Storage

</td>  
<td>

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

#  9\. CONCLUSION

This Data Management Plan provides an overview of the framework of the data
management pertaining the EPICA project. Moreover, it describes the expected
sources, from where the data will be sourced from and the compliance to the
FAIR principles, cf. Section 4.

This framework is dynamic and expected to be enriched and elaborated within
the project lifetime. As the project is in its first 18-months of the project
cycle, it has proven difficult to make estimates regarding the volume of user
data that will finally preserved in the developed ePortfolio as well as the
different costs required for their preservations. This will be an area of
focus in the period between M18 and M36, and is closely tied to the advances
in the development of the ePortfolio. Concerning the project data however
(requirements, business development information and similar/other), the DMP in
its current form draws up the boundaries for the processing and management of
the data.

The ongoing work to be performed in the next months is generally expected to
generate useful data in order to provide more accurate information on the data
management. The document will keep being updated along with the EPICA
progress, and as such one more final version of D1.4 is going to be developed
based on the available findings during its corresponding period.

These versions will be delivered:

~~1\. Second version: M12~~

~~2.~~

~~Third version:~~

~~M18~~

3\.

Fourth version:

M36

_**Figure 6:** _

_Schedule for current and future revised EPICA DMPs_

10\. APPENDIXES

Self-declarations of GDPR compliance from project partners in Non-EU/EEA
Countries for the purpose of data transfer and processing available upon
request from the EPICA DPO.

**_Letter template/text):_ **

To be provided on the institution's letterhead to ICDE as coordinator:

**Recipient:**

_EPICA Legal, Ethics and Data Protection Officer_

_(NAME)_

_ICDE - International Council for Open and Distance Education Drammensveien
211, 0281 Oslo, Norway_

**Headline:** _Certification Attesting the Commitment to the EPICA Data
Management Framework_

**Text:**

_This is to certify that the_ ***NAME OF INSTITUTION/COMPANY*** _has
implemented the mandatory legal measures in relation to data protection and
operate in accordance with the established guidelines by national legislation,
the EU General Data Protection Regulation (GDPR) and the at any time
applicable project data management framework (DMP) as a partner in the EPICA
project_ .

**Signature:** _Your signature and title, and preferably institution’s
stamp/seal_