D1.4 Privacy and Data Protection Framework

This project has received funding from the European Union’s Horizon 2020 research and innovation
programme under Grant Agreement No 826304
THEME [SC1-DTH-03-2018]
Adaptive smart working and living environments supporting active and healthy ageing
„Personalized Body Sensor Networks with Built-In Intelligence for Real-Time Risk
Assessment and Coaching of Ageing workers, in all types of working and living
environments”
Project Reference No 826304
Deliverable D1.4 Privacy and Data Protection Framework
Workpackage WP1: Overall Framework Definition
Nature D (Deliverable)
Dissemination Level RP (Restricted to other programme participants (including

Commission Services))
Date 31/12/2019
Status FINAL
Editor(s) Kalloniatis C (UPRC), Lambrinoudakis C (UPRC), Lyvas C.

(UPRC), Kanatas A. (UPRC), Gritzalis S. (UPRC), E.L. Makri
(UPRC), V. Nikolaidis (UPRC)
Document Description The purpose of this deliverable is the description of a privacy

and data protection framework that will be applied at the early
stages of the BIONIC system design for guaranteeing that the
development of the applications / architecture will follow a
privacy-by-design approach ensuring the satisfaction of all
Restricted 09.02.2020 D1.4
functional requirements but also of all non-functional (security

and privacy) related requirements imposed by the users. The
ouput of this deliverable includes a set of organisational/legal
requirements ensuring the compliance of BIONIC with GDPR
requirements along with a list of high-level security and
privacy technical requirements elicited from the proposed
privacy and data protection framework.
Page 2 of 124
DOCUMENT HISTORY
Version Date Description Main author (unit)
0.2 10.07.2019 Definition of the document’s structure C. Kalloniatis (UPRC)
C. Lambrinoudakis (UPRC)
A. Kanatas (UPRC)
0.3 15.07.2019 Description of the BIONIC System C. Kalloniatis (UPRC)
A. Kanatas (UPRC)
0.4 20.08.2019 Review on Privacy and eHealth Systems C. Lambrinoudakis (UPRC)
S. Gritzalis (UPRC)
A. Kanatas (UPRC)
0.5 31.08.2019 GDPR and Privacy by Design C. Kalloniatis (UPRC)
0.6 20.09.2019 Privacy and Data Protection Framework – C. Kalloniatis (UPRC)

Generic Description and outline
C. Lyvas (UPRC)
0.7 05.10.2019 Analysis of the proposed Data Protection C. Kalloniatis (UPRC)

Framework
C. Lyvas (UPRC)
0.8 13.10.2019 Description of the Privacy Impact C. Lambrinoudakis (UPRC)

Assessment Method
S. Gritzalis (UPRC)
E.L. Makri (UPRC)
V. Nikolaidis (UPRC)
0.9 5.12.2019 Application of stage 1 of the proposed C. Kalloniatis (UPRC)

framework
C. Lyvas (UPRC)
1.0 07.12.2019 Application of stage 1 of the proposed C. Kalloniatis (UPRC)

framework – Formatting and updating
text in sections 2 and 3
Page 3 of 124
Version Date Description Main author (unit)
1.1 08.12.2019 Application of stage 2. Formatting and C. Kalloniatis (UPRC)

updating text in sections 2 and 3
A. Kanatas (UPRC)
C. Lyvas (UPRC)
E.L. Makri (UPRC)
1.2 17.12.2019 Application of stage 3. Formatting and C. Kalloniatis (UPRC)

updating text on the whole deliverable
C. Lyvas (UPRC)
E.L. Makri (UPRC)
Page 4 of 124
CONTENTS
List of Tables ........................................................................................................................................... 7
List of Figures .......................................................................................................................................... 8
List of Abbreviations ............................................................................................................................... 9
1 Introduction .................................................................................................................................. 10
1.1 Purpose of the document .................................................................................................... 10
1.2 Structure of the document .................................................................................................. 10
2 BIONIC System and Use Cases....................................................................................................... 12
2.1 Brief Description of the BIONIC System ............................................................................... 12
2.2 The BIONIC Data Flow .......................................................................................................... 13
2.3 Introducing Privacy in BIONIC .............................................................................................. 15
2.4 End Users and Use Case Stories ........................................................................................... 18
3 Privacy and Data Protection Framework ...................................................................................... 24
3.1 Introduction ......................................................................................................................... 24
3.1.1 The emerge of eHealth and mHealth Systems ................................................................ 24
3.1.2 Privacy issues within eHealth .......................................................................................... 24
3.1.3 GDPR purposes and principles......................................................................................... 25
3.1.4 Compliance to GDPR ....................................................................................................... 28
3.1.5 Privacy by Design Schemes under GDPR ......................................................................... 29
3.1.6 Security and Privacy requirements within eHealth systems ........................................... 30
3.1.7 Privacy Safeguard (PriS) under GDPR .............................................................................. 32
3.2 Description of the Framework ............................................................................................. 35
3.2.1 Stage 1: Personal Data handling processes elicitation .................................................... 36
3.2.2 Stage 2: Compliance Level on GDPR requirements ......................................................... 37
3.2.3 Stage 3: Security and Privacy requirements elicitation ................................................... 39
3.2.4 Stage 4: Data Protection Impact Assessment .................................................................. 41
4 Application of the Privacy and Data Protection Framework ......................................................... 46
4.1 Stage 1: Personal Data Handling Processes Elicitation ........................................................ 46
4.2 Stage 2: Compliance Level On GDPR Requirements ............................................................ 49
4.2.1 Introduction..................................................................................................................... 49
4.2.2 Gap Analysis Results ........................................................................................................ 49
4.3 Stage 3: Security and Privacy Requirements Elicitation....................................................... 66
4.3.1 Introduction..................................................................................................................... 66
4.3.2 Step 1: Identify System Assets, Stakeholders, Security and Privacy Goals ...................... 67
4.3.3 Step 2: Security and Privacy Threats and related System Vulnerabilities ....................... 71
Page 5 of 124
4.3.4 Step 3: Security and Privacy Requirements ..................................................................... 86

4.4 Stage 4: Impact Estimation from Security/Privacy Violation Incidents................................ 88
5 Conclusion and Next Steps ............................................................................................................ 89
6 References .................................................................................................................................... 90
7 APPENDICES .................................................................................................................................. 95
7.1 APPENDIX A: Questionnaire for Stage 1 ............................................................................. 95
7.2 APPENDIX B: Data Flows Among BIONIC Components and Technologies Implementing the
Required Communication Links ........................................................................................................ 98
7.3 APPENDIX C: Elicitation of Security and Privacy Requirements for the BIONIC System ... 102
Page 6 of 124
LIST OF TABLES
Table 1. Use cases for the construction and manufacturing context ..................................................... 18
Table 2. Matching GDPR privacy principles with PriS privacy requirements .......................................... 34
Table 3. Categories of data for Purpose of Processing “Evaluate medical data to improve employees
health”................................................................................................................................................... 46
Table 4. Sources of data for Purpose of Processing “Evaluate medical data to improve employees
health”................................................................................................................................................... 47
Table 5. Categories of data for Purpose of Processing “Evaluate medical data to improve working
conditions” ............................................................................................................................................ 48
Table 6: Description of the Status of Controller’s Activities for ensuring GDPR Compliance for the
BIONIC system ....................................................................................................................................... 49
Table 7: Summary of the Gap Analysis findings for the PP1 of the BIONIC system in relation to the
requirements of the General Data Protection Regulation 2016/679 (GDPR) ........................................ 50
Table 8: Overall GDPR compliance level for the BIONIC system ............................................................ 53
Table 9: Status of the Controller’s Activities for ensuring compliance of the BIONIC system with the
GDPR requirements ............................................................................................................................... 53
Table 10: Findings of the Gap Analysis for the PROCESSING ACTIVITY PP1 of the BIONIC system in
relation to the requirements of the General Data Protection Regulation ............................................. 55
Table 11: GDPR requirements derived from GAP analysis ..................................................................... 65
Table 12: Assets of the BIONIC System .................................................................................................. 68
Table 13: BIONIC Communication Channels .......................................................................................... 70
Table 14: BIONIC User Roles .................................................................................................................. 70
Table 15: BIONIC Security and Privacy Goals ......................................................................................... 71
Table 16: Threats against BIONIC assets ................................................................................................ 72
Table 17: Vulnerabilities that can be exploited by each identified Threat ............................................. 77
Table 18: Security and Privacy Requirements for the BIONIC System ................................................... 86
Table 19: Data Flows among Bionic Components .................................................................................. 98
Table 20: Technologies Implementing the Required Communication Links ........................................ 101
Page 7 of 124
LIST OF FIGURES
Figure 1. The BIONIC data flow .............................................................................................................. 14
Figure 2. Body Sensor Networks for ageing workers, managers and doctors ........................................ 17
Figure 3. GDPR- Significant changes for EU citizens’ data protection .................................................... 26
Figure 4. Associating GDPR approach with PriS Methodology ............................................................... 33
Figure 5. GDPR Compliant Personal Data Management Methodology .................................................. 36
Figure 6. Output of Stage 1.................................................................................................................... 37
Figure 9. Conceptual Framework of Impact Assessment ....................................................................... 43
Figure 10. Risks and Feared events........................................................................................................ 44
Figure 11. Factors used to estimate risks .............................................................................................. 44
Figure 12. Output of Stage 4.................................................................................................................. 45
Figure 13. Compliance level (%) per Article Category for the BIONIC system ........................................ 51
Figure 14. Percentage (%) of the activities completed by the Controller for ensuring compliance of the
BIONIC system with the GDPR requirements ........................................................................................ 52
Figure 15. Graphic depiction of the overall GDPR compliance level for the BIONIC system .................. 53
Figure 16. Graphic depiction of the status of the Controller’s Activities for ensuring compliance of the
BIONIC system with the GDPR requirements ........................................................................................ 54
Figure 17. Architectural view of the BIONIC System for the Security and Privacy Analysis .................... 68
Figure 18. Questionnaire for Supporting Stage 1................................................................................... 97
Page 8 of 124
LIST OF ABBREVIATIONS
Term / Abbreviation Definition

GDPR General Data Protection Regulation
RRPS Rolls-Royce Power Systems
OHS Occupational Health and Safety
IMU Inertial Measurement Unit
ESM Experience Sampling Methods
AI Artificial Intelligence
PA Physical Activity
BSN Body Sensor Network
HCI Human Computer Interaction
MSD Musculoskeletal diseases
Page 9 of 124
1 INTRODUCTION
1.1 PURPOSE OF THE DOCUMENT

The specific deliverable D.1.4 “Privacy and Data Protection Framework” presents the framework that
will be used for conducting the analysis related to the elicitation of the organizational, technical and
procedural requirements regarding the security and privacy requirements for the BIONIC project. The
deliverable is the result of Task 1.3. “Privacy and Data Protection Framework”.
One of the main goals of the BIONIC project is the development of three software applications targeting
the workers, the managers and the doctors for satisfying the goal of developing an integrated prototype
for monitoring worker’s health condition and making suggestion for improving it during working hours
as well as at home through respective coaching applications. Thus, it is important to make all engaged
users trust the developed applications and especially the workers whose personal data are disseminated
in various forms for supporting different functionalities.
The purpose of this deliverable is the description of a privacy and data protection framework that will
be applied at the early stages of the BIONIC system design for guaranteeing that the development of
the applications / architecture will follow a privacy-by-design approach ensuring the satisfaction of all
functional requirements but also of all non-functional (security and privacy) related requirements
imposed by the users. Furthermore, during the design phase all, legal and technical, requirements of
the General Data Protection Regulation (GDPR) should be considered. Indicatively, it will be ensured
that principles like the data protection (purpose limitation, data minimization, accuracy, accountability),
the lawfulness of processing, the user consent, are fully satisfied. The applications will respect all the
rights of the data owners (workers) like their right to object to the storage/processing of their
information, their right to be forgotten, their right to restriction of processing etc. Finally, all necessary
technical, organizational and procedural measures will be considered to address the GDPR
requirements related to data protection, accountability and handling of potential data breaches.
Beside the description of the proposed privacy and data protection framework this deliverable aims to
identify and present the initial high-level security and privacy requirements elicitation by analyzing both
the GDPR related processes as well as the technical security and privacy requirements derived from the
functional requirements of the BIONIC system. The whole list of security and privacy requirements that
should be fulfilled form all BIONIC applications will be derived based on the proposed Privacy and Data
Protection Framework.
1.2 STRUCTURE OF THE DOCUMENT

This document is structured as follows:
Chapter 2 – BIONIC System and Use Cases: Brief description of the BIONIC system and the proposed
data flow and the generic categories of data captured necessary for the BIONIC project. A brief
description of the security and privacy issues raised in BIONIC is also included.
Chapter 3 – Privacy and Data Protection Framework: Description of the different methods for security
and privacy requirements engineering in ehealth environments, literature research on privacy by design
principle and GDPR, description of the proposed Privacy and Data Protection Framework.
Chapter 4 – Application of the Data Protection Framework: Description of the purposes of processing
for the BIONIC project and the categories of data in each case. Applicability of the proposed privacy and
Page 10 of 124
data protection framework for every purpose of processing leading to the elicitation of the respective
security and privacy requirements that have to be realised in the proposed applications.
Chapter 5 - Conclusion and next steps: The results will be summarized and linked to future work
packages and more specifically on Work Package 6, Task 6.6 related to Data protection security and
privacy measures and task 6.7 related to Data Protection Policies.
Page 11 of 124
2 BIONIC SYSTEM AND USE CASES
2.1 BRIEF DESCRIPTION OF THE BIONIC SYSTEM

BIONIC is a pioneering system, funded by the European Union’s Horizon 2020 research and innovation
programme under Grant Agreement No 826304, which provides industry with a unified methodology
focused on the perspective of ageing in the workplace, by supporting its application in research.
Its mission has been manifold, aiming at the development of a a) holistic, unobtrusive, b) autonomous
and c) privacy preserving platform for real-time risk alerting and continuous persuasive coaching,
enabling the design of workplace interventions adapted to the needs and fitness levels of specific ageing
workforce. Since many typologies of industry jobs are physically demanding, it is necessary to support
the aging workforce with appropriate tools that can help them to stay at their jobs, assessing the
potential impacts of their work activities on their health, and recommending exercises to mitigate those
impacts and promote healthy and active lifestyles. In this regard, the BIONIC solution constitutes a
valuable tool for achieving these objectives, bringing medical wearable technology into a new paradigm
accordingly to the World Health Organisation principles for e-Health (WHO, 2015) and m-Health (WHO,
2011), by integrating sensor modules in multi-purpose, configurable Body Sensor Networks (BSNs)
introducing key enablers of user acceptance based on value, comfort, confidence and trust.
Configurable BIONIC Body Sensor network has been originally conceived as a platform combining a wide
variety of connected sensors enabling the build-up of a real-time holistic data model of the human body,
by capturing static and dynamic whole-body information, such as e.g. body posture, gait, running style,
etc., possibly combined with key bio-signals, such as body temperature, heart rate, and environmental
signals. Dynamic monitoring of overall body posture, integrated into everyday or work clothing will
significantly promote the wide adoption of motion tracking wearables, by eliminating the need to attach
sensing devices firmly to the body, thus affecting comfort and possibly impeding movement during work
or everyday / physical activity. Existing commercial wearables with open APIs (e.g. smartwatches, sole
pressure sensors) will also be integrated to enable a holistic integrated continuum of data to derive self-
quantification information. Depending on the specific chronic MSD condition, body-part specific BSN
modules in the form of e.g. belts or bandages (for monitoring lower back and knee chronic MSD) will be
developed. Detailed monitoring of these body parts will be based on innovative localized biomechanical
models, focusing on age-induced constraints and chronic impairments (age adapted body - part specific
models). Additionally BSN allows freedom in the selection and positioning of the sensors on the body,
depending on the requirements of the specific application (fitness, performance, medical, ergonomics
etc.), while it enables the development of customizable or even multi-functional wearables, i.e.
networks with inherent redundancy of sensors, with their functionality configured by application
software.
Another major key innovation relates to the concept of AI on a chip, i.e. embedding predictive Artificial
Intelligence algorithms in the Body Sensor Network (BSN). Raw data pre-processing at the source
prevents immense flows of data being transmitted to remote gateways. Feature extraction at the source
will result in informative and non-redundant features, ready to be fed into artificial neural networks.
The combination of such machine learning algorithms with biomechanical model-based estimation will
allow for deducing relevant and interpretable parameters for efficient real-time, in-field and long-term
personalized risk / physical strain and recovery assessment from individual sensor data.
Therefore, continuous personalized on-site assessment of the real capacity of ageing workers, using
BIONIC wearables, will allow to derive valuable information both at a personal, as well as at a statistically
Page 12 of 124
relevant age dependent level, associating the imbalances and risks with design criteria and
recommendations that facilitate the selection and adaptation of appropriate positions, while ageing
workers will keep their personal data private. Feedback to the user will be provided in real-time through
the BSN to actuators such as haptic, acoustic, visual systems. Communication to external Network is
optional and under control of the user, who can decide case by case who will get access to the results
or the raw data. To fulfil that, an integrated prototype of monitoring and data presentation software
will be used, including three different applications targeting: a) workers, where self-monitoring
application providing access to their movement data such as daily and archived statistics, risks identified
and exercise recommendations, incorporating advanced UX and intuitive ways of human computer
interaction to accommodate ageing users’ requirements, ensuring optimum comprehension of the
relevant warnings and advice and maximizing the preventive effect of the system, b) managers: where
ergonomic risk assessment applications provide real-time feed of selected worker movement
information to construction site managers to allow for injury prevention as well as periodical reports,
including assessment results and recommendations for workplace interventions and c) doctors, where
specially designed application provide doctors with access to workers movement and health
information, efficiently structured and prioritized based on ergonomic risk, allowing doctors to support
the workers in a timely manner.
In this sense, BIONIC introduces Body Sensors Networks in the everyday life to a market segment, which
is not so easy for wearable electronics solutions to reach, i.e. older individuals. BIONIC’s strong focus on
usability and privacy aspects (e.g. HCI, gamified coaching, GDPR principles) will bring these users the
confidence and trust to try more similar solutions which can improve their quality of life. It will also
convince them in practice that such technology is not only for the gadget savvy youths but can provide
real value related to their health and wellbeing. This integrated methodology within a broader
procedure is able to facilitate aspects such as, the management of experience in companies, the transfer
of knowledge or the transition to retirement, that are relevant aspects for improving companies
productivity and competitiveness.
2.2 THE BIONIC DATA FLOW

The BIONIC project supports two main types of services. The first is conducted during the working hours
where every worker receives live feedback form the Body Sensor Network that he/she wears while the
second is performed during leisure time with the support of a “lighter” Body Sensor Network consisting
of less sensors than the full BSN.
More specifically, the full BSN network consists of a set of sensors attached on a jacket that the worker
wears during his/her work. These sensors provide raw data to an AI chip (also located in the jacket)
which generates processed data related to the workers current health status. The AI chip interacts with
the worker’s smart watch mostly for getting additional information for the worker’s statues (e.g. heart
rate) and for sending notifications to the worker (e.g. alarm messages). Also the worker possesses a
mobile device for handling his/her data and interacting with BIONIC apps as well as for conducting the
coaching exercises at home.
The “light BSN” is the body sensor network consisting from the worker’s smartwatch), some IMU
sensors and a mobile device and is used from the worker during his leisure time (not working hours) to
exercise himself/herself based on the coaching app of the BIONIC project. Beside the use of the specific
app the light BSN monitors worker’s ergonomic and health data for capturing his/her habits and moves
outside the working environment in order to prevent unwanted situation and/or to better advise the
worker during the day.
Page 13 of 124
The proposed BIONIC data flow is presented in the following figure. The full BSN and the light BSN parts
are also visible in the figure.
Figure 1. The BIONIC data flow
Based on the aforementioned figure BIONIC will collect all processed data (as exported from BSN) in a
secure storage in order for the developed apps to have access on and mainly provide the necessary
feedback to the worker. The data produced by the light BSN will also be stored in the secure storage
repository if the worker wishes to do so. For R&D purposes and only for the duration of the project the
raw data produced by the BSN network will be stored in an anonymised form in a separate database
called “Research Data” in the respective figure.
Regarding the types of data collected from the BSN and light BSN networks are mainly the following:
• Kinematic data, probably at IMU sample rate (e.g. joint angles)

• Kinetic data, probably at lower sample rate (e.g. vertical ground reaction force, ground contact
information, external load indicators)
• Depending on chosen ergonomic tools:
Page 14 of 124
o timestamped detected events (e.g. picking something up, body positions) and
repetitions
o possibly ergonomic scores
• Physiological data (Heart rate, blood pressure, body temperature)
The aforementioned list will be refined and thoroughly examined for security and privacy implications
under the Privacy and Data Protection Framework proposed in section 3 while in chapter 4 every type
of data will be linked with the specific purpose of processing with the BIONIC system prior to the specific
security and privacy requirements that will be implemented for safeguarding the BIONIC applications.
2.3 INTRODUCING PRIVACY IN BIONIC

BIONIC, having acknowledged that the ageing population in Europe impacts multifaceted on the EU
productivity growth (Carbonaro et al., 2018; Sharma, 2016) and rises healthcare costs which are leading
to the necessity of developing new digital forms of health self-management systems outside the health-
care services (Petrakaki, Hilberg & Waring, 2018), provides the development of medical wearables
applications for personalized information and treatment to ageing workers of the following use-cases
(see 2.4.), as a form of an e-health system (Drosatos et al., 2016), aiming to assist them in managing
their health issues and maintaining behaviors that promote health, so as to improve the quality of their
work and life.
In general, medical apps enable remote health monitoring, but also, due to the basic personal e-health
systems’ functionalities, such as: personal data storage and processing, personal data exchange with
other third party systems (personal or institutional), integration of (personalized) public data, exporting
personal data for statistical use and exchange of private personal data messages (Drosatos et al., 2016),
they are raising security and privacy concerns, which are considered to be some of the most important
barriers for the fully implementation of e-healthcare solutions (Mustafa, Pflugel & Philip, 2019). The
“privacy paradox” significantly affects the effectiveness of existing solutions, since most users are
concerned about the protection of their medical data and at the same time they agree on using these
devices since they are vital for their health (Lee & Kwon, 2015). There are also cases of users who are
not aware of the potential harm that can be caused from a deliberate or an accidental threat. In general,
privacy and personal data protection constitutes a major concern for e-health consumers (Zhang et al.,
2018), impacting wearables adoption. Indicatively, 82% of the respondents to a PwC survey reported
that they are worried that wearable technology will invade their privacy (PwC, 2014). Therefore, users’
acceptance is strongly dependent on trust.
Additionally, the principles enforced by the new General Data Protection Regulation (GDPR) put special
emphasis on the protection of citizens’ privacy by elevating the obligations of the parties collecting,
distributing and processing users’ data (Kurtz, Semmann & Böhmann, 2018). To this respect privacy
engineering has gained much attention in Europe, and lately across the Atlantic, as a significant part of
the system development process where IT security and privacy software engineers along with
developers should define the principles in the form of technical requirements that need to be satisfied
in order for the system to ensure a minimum level of security and being trustworthy for the citizens
(Martin & Kung, 2018). Thus, as far as the e-health and m-health systems concerns, which are critical
due to the sensitivity of the collected and distributed data within them, security and privacy have been
always of immense interest to research communities. However, most of previous research (Alagar,
Periyasamy & Wan, 2017; Alibasa et al., 2017; Zhou et al., 2015; Volk, Sterle & Sedlar, 2015) focusing on
the security and privacy frameworks for m-health applications that provide users with more control
regarding the use of their sensitive health data within then, does not combine the benefits of privacy
Page 15 of 124
engineering along with the new technical and legal aspects of GDPR legislation in medical wearables
applications, while some interesting approaches aiming to highlight the privacy requirements of the m-
health applications within the context of GDPR, focus only on specific target group of patients, such as
Mustafa, Pflugel & Philip (2019) study regarding patients suffering from Chronic Obstructive Pulmonary
Disease, excluding larger or healthier target groups in which m-health applications are also addressed.
Taking all these into consideration, BIONIC, going beyond previous research, introduces medical
wearables to the workplace in order to form a strong paradigm of how wearable technology can respect
the user’s rights to privacy, maintaining the highest standards in terms of privacy and data protection,
and to familiarize many users with these rights and their ability to control the sharing of their data. In
this regard, it provides a flexible and efficient security and privacy requirements engineering
methodology for eliciting security and privacy requirements followed by a Privacy and Data Protection
Framework (see 3.2.) consisting of the appropriate technical, organizational and procedural measures
for the satisfaction of those requirements. The requirements elicitation methodology support threat,
vulnerability and attack analysis, reasoning on security and privacy requirements and modelling of the
system. The use of Privacy by Design methods is very critical for capturing the aforementioned
information following the whole software development lifecycle. It is also of major importance that the
proposed Privacy and Data Protection Framework complies with GDPR legislation. Additionally,
particular attention has been given on the different categories of personal data that are processed by
the BIONIC platform, such as sensitive data, including recent developments in the field of biometric and
health-related data. It also ensures that the applications respect all the rights of the data owners
(workers) like their right to object to the storage/processing of their information, their right to be
forgotten, their right to restriction of processing etc.
To that aim, an integrated prototype of monitoring data presentation software has been developed with
reference the three above mentioned different applications targeting workers, managers and doctors.
The development of the applications follows the proposed privacy-by-design approach, ensuring the
satisfaction of all functional requirements, but also of all non-functional (security and privacy) related
requirements imposed by the users. Furthermore, during the design phase, all legal and technical
requirements of the General Data Protection Regulation (GDPR) have been considered, while all
necessary technical, organizational and procedural measures to address the GDPR requirements related
to data protection, accountability and handling of potential data breaches have been taken into
consideration. Respectively, it is ensured that principles like the data protection (purpose limitation,
data minimization, accuracy, accountability), the lawfulness of processing, the user consent, are fully
satisfied. The applications respect all the rights of the data owners (workers) like their right to object to
the storage/processing of their information, their right to be forgotten, their right to restriction of
processing etc.
Page 16 of 124
Figure 2. Body Sensor Networks for ageing workers, managers and doctors
Apart from the data presentation applications, a separate application has been implemented to allow
workers to have complete control of what parts of their captured data is shared with their employers
and their doctors. The User Interface of this application has been designed with great care to ensure
maximum comprehension and transparency of data sharing, independent of age, familiarity with
technology or culture. Users have an easy and intuitive way to view and revise exactly which parts of
their data they agree on sharing and which party they are sharing it with (e.g. employer, doctor etc.) at
any time. Especially this last issue, approached through the specialized application with the aim of giving
the user complete control over their data, can provide the reassurance the users need, leading in a
much wider adoption of similar solutions but also educating them so that they can avoid other less
secure options in the market. Moreover, from a purely technological aspect, intelligent sensor data
fusion and analysis at the edge, on its own ensures that the data transmitted from the device is only
data which is relevant to the overall aim (i.e. ensuring the workers wellbeing) and does not include
redundant information which could be used for other purposes (e.g. worker performance assessment).
This is a very innovative and important approach as a lot of the users concerns come from the vast and
catholic collection of raw data, currently by many wearables providers or other online companies with
no clear indication of why this data is collected and how it is used. BIONIC’s impact will thus be a new
level of trust built between wearable technology and users.
Consequently, BIONIC covers the gaps in existing methodologies through the development of a unified
privacy by design methodology, focusing on the increase of the end users’ trustworthiness to the
developed software and more specifically on: a) the combination of privacy by design principles with
the newly introduced GDPR requirements in order to create a strong elicitation process for deriving the
set of technical requirements that should be addressed and also to propose a process for validating that
the elicited requirements are indeed fulfilling the objectives addressed during the Data Protection
Impact Assessment (DPIA), carried out according to the GDPR , b) the increasement of the end users’
ability to trace their personal data by offering easy to use services, via a mobile application, in order to
have full control over their data regardless of their security and privacy awareness level and c) usability
and user experience criteria, which are combined in the proposed methodology under a unified
framework along with the elicited technical requirements. Finally, the implementation of new concepts,
such as privacy and data protection by design and by default, accountability, data minimization,
lawfulness of processing, and users’ consent in e-health and m-health systems are analyzed, since
Page 17 of 124
different stakeholders from several workplaces and domains with different backgrounds may
understand the same terms in different ways, while the elaboration and mapping of the allocation of
liability between different actors in interconnected platforms is conducted, as well as procedures for
handling potential data breaches.
2.4 END USERS AND USE CASE STORIES

As described in D.1.3 the use cases that will be considered for the elicitation of the functional
requirements of the BIONIC platforms are following the construction and the manufacturing context
since these are the activities of the two end users of the project (RRPS and ACCIONA). The use cases as
describe in the aforementioned deliverable are presented in the table below.
Table 1. Use cases for the construction and manufacturing context
Manny - Industry Manuel - Construction
Background Manny is a 55 years old male, working Manuel is a Spanish construction

story for more than 25 years at RRPS. He is in worker and 50 years old. He has been
an assembly line handling manual labor working in construction for 30 years
tasks, working 7 hours a day, 35 hours a now. He works 5-6 days a week for 8-10
week. Recently, his work changed into hours, with a short break in the
shift work, sometimes he has to start at morning, a one hour lunch break
5 in the morning. In the morning, he has around 14.00 and then he works until
a 15 minute breakfast break and in the the end of the day. In summer, the work
afternoon he has a 45 minute lunch days are longer and when it is really hot,
break. He can go to a social room or go he must stop working in the middle of
outside to the store or to smoke. the day.
Like many of his co-workers, Manny is Manuel is a bricklayer, involving the

from a farming family, which means following activities: carrying equipment
that at home lots of work needs to be to his work place, mixing the concrete,
done for their vineyard. However, his cutting the bricks, and the brick laying
wife is doing most of this, as Manny acts itself. During brick laying, Manuel starts
like a couch potato as soon as he at ground level and works his way up as
returns from work. the walls grow. During work, he wears
work pants, security shoes, a simple t-
Manny suffers from low back pain,
shirt, and sometimes gloves and a
which is a common problem for people
safety vest. Manuel notices that most
in the production lines. He received
accidents and injuries happen at the
painkillers for it by the company doctor,
end of the day, when he and his
but his work activities did not change.
colleagues get tired. Most injuries are
He also has a lack of energy all the time
back injuries, but once he had the
and is not sleeping very well. He is now
carpal tunnel syndrome, because he
visiting a physical therapist and does
must hit the bricks to firmly place them
exercise at the gym at work in his free
on the cement.
time, but he does not go there very
much. On his free days, Manuel does not really
do exercise. He likes lying on the couch
and sometimes he goes shopping with
his wife. He does not really have
Page 18 of 124
computer experience, but he owns a

smartphone that he uses to call and
text. Manuel only finished high school
and learned all the needed skills
through his extensive work experience.
Assigning the Manny visits his company doctor as he Manuel suffers from back pain. He has
system suffers from low back pain. The visited his general practitioner (GP) who
company doctor decides with the told him that it might be due to work.
occupational health and safety (OHS) The GP has referred him to the
specialist that Manny might benefit occupational health and safety (OHS)
from the BIONIC system. They offer specialist of his company. The OHS
Manny to use the system for three specialist assigns Manuel to the BIONIC
weeks to identify risks relating to his system for three weeks during work and
back problems and to offer feedback. at home to support him in improving his
health condition.
Introduction to Manny is invited for an introduction Manuel is invited for an introduction

the system session with the BIONIC system. An OHS session with the BIONIC system. An OHS
team member (administrator) has sent team member (administrator) has sent
Manny a link to the BIONIC app and Manuel a link to the BIONIC app and
before the session, Manny downloads before the session, Manuel downloads
the app on this own Android the app on this own Android
smartphone. During the session, Manny smartphone. During the session,
receives log-in details from the OHS Manuel receives log-in details from the
specialist and logs in for the first time OHS specialist and logs in for the first
on the BIONIC platform, where he first time on the BIONIC platform, where he
accepts and signs the agreement which first accepts and signs the agreement
explains to him data privacy, retention which explains to him data privacy,
policy, and legal rules. Together they retention policy, and legal rules.
complete the user profile (age, gender, Together they complete the user profile
weight, length). A medical team (age, gender, weight, length). The OHS
member takes two pictures of Manny specialist takes two pictures of Manuel
to determine his body morphology, and to determine his body morphology, and
take some measures (segment length, take some measures (segment length,
etc.) which is necessary to personalize etc.) which is necessary to personalize
the BIONIC system. The morphology the BIONIC system. The morphology
will be entered in the profile and the will be entered in the profile and the
pictures will be deleted. In addition, pictures will be deleted. In addition,
they together enter the reason for they together enter the reason for
using BIONIC / medical goal e.g. using BIONIC / medical goal e.g.
prevention back pain). This information prevention back pain). This information
is needed to determine the optimal is needed to determine the optimal
Page 19 of 124
feedback strategy provided by the feedback strategy provided by the

BIONIC system that helps Manny in his BIONIC system that helps Manuel in his
health and working conditions. In the health and working conditions. Manuel
settings menu, Manny has given also receives instructions how he can
permission to the company doctor to share his data and progress with his GP.
share his processed data and progress.
Manuel then receives the BIONIC work
Manny then receives the BIONIC work clothes, similar to the ones he wears
clothes, similar to the ones he wears during work. He also receives a
during work. He also receives a smartwatch and charger.
smartwatch and charger.
Starting the Before Manny goes to work, he puts on Before Manuel goes to work, he puts on
BIONIC system his smartwatch and BIONIC sensing his smartwatch and BIONIC sensing
clothes. He then arrives at work and short. When Manuel arrives in the
activates the connection with his construction site, he activates the
smartphone by clicking ‘start connection with his smartphone by
measurement’. After a short calibration clicking ‘start measurement’ and
he can start his shift at the production performs a short calibration after which
line. he starts with work.
System at work While Manny is working, the system While Manuel is working, the system
measures posture, movements, measures posture, movements,
handling of loads and fatigue (using handling of loads and fatigue (using
IMUs in the BIONIC clothes a heart rate IMUs in the BIONIC clothes, a heart rate
sensor in the smartwatch, and pressure sensor in the smartwatch, and pressure
sensor insoles). During his breaks, sensor insoles). During his breaks,
Manny enters how he has been feeling Manuel enters how he has been feeling
in the smartphone in the smartphone
application/smartwatch (ESM). On the application/smartwatch (ESM). On the
smartwatch, Manny can easily see/feel smartwatch, Manuel can easily see/feel
at a glance how he is doing of if there at a glance how he is doing of if there
are risky situations, as he receives are risky situations, as he receives
personal real-time alerts (based on personal real-time alerts (based on
alarms generated on the AI chip). alarms generated on the AI chip).
Stopping the When Manny finishes his shift, he walks When Manuel finishes work, he walks
system at work back to the changing rooms. He checks to his car. In the car, he remembers to
his smartphone and enters one more check his smartphone and to enter one
time how he has felt during work, more time how he has felt during work,
before clicking ‘end measurement’. This before clicking ‘end measurement’. This
automatically ensures that the automatically ensures that the
processed data is sent to the cloud, processed data is sent to the cloud,
unless Manny indicates otherwise. unless Manuel indicates otherwise.
Manny takes off his BIONIC clothes and Manuel drives home while wearing the
brings it to the laundry facility for a BIONIC clothes and smartwatch. At
machine wash and charging. He then home, he changes into comfortable
Page 20 of 124
goes home while still wearing the clothes and puts the BIONIC clothes in
smartwatch. the washing machine.
System at home After his shift and at home, Manny only At home, Manuel only uses the BIONIC
uses the BIONIC light, consisting of the light, consisting of the smartwatch
smartwatch (heart rate, PA) and (heart rate, PA) and smartphone app
smartphone app (PA, fatigue, ESM). (PA, fatigue, ESM). This data is stored
This data is stored locally on the phone. locally on the phone. As soon as Manuel
As soon as Manny is back at work, the is back at work, the data is transferred
data is transferred automatically and automatically and wirelessly to the
wirelessly to the cloud. This data from cloud. This data from the BIONIC light
the BIONIC light outside working hours outside working hours is not available
is not available to doctors, unless stated to the company managers.
by Manny otherwise in settings (de-
Manuel sits down on the couch and
activate/activate).
checks on his smartphone how his shift
At home, Manny checks how his shift went. In the cloud, the risk profile of
went on the smartphone. In the cloud, Manuel was automatically updated
the risk profile of Manny was based on the risk assessment by the
automatically updated based on the risk system. This data is shown in an
assessment by the system. This data is understandable and engaging way on
shown in an understandable and his smartphone, where he can see his
engaging way on his smartphone, progress in relation to his goal (e.g.
where he can see his progress in prevent back pain), work load and his
relation to his goal (e.g. prevent back general fatigue at work and outside
pain), work load and his general fatigue working hours. Manuel receives
at work and outside working hours. feedback advices on how to improve his
Manny receives feedback advices on risks and fatigue outside working hours.
how to improve his risks and fatigue For example, by offering personal
outside working hours. For example, by exercise schemes on the smartphone to
offering personal exercise schemes on help him in achieving better health
the smartphone to help him in goals. Manuel can perform these
achieving better health goals. Specific exercises at home. Today, the system
exercises are proposed, which can be recommends Manuel to go for a short
adapted by the doctor if needed. walk and then do some stretching
Manny can decide when to share his exercises. His smartwatch monitors
data to the doctor or occupational whether Manuel went for a walk and
safety specialist, when he wants checks how relaxed he is using his heart
additional feedback or coaching. He can rate. The system recommends Manuel
perform these exercises at home or at does his exercises and receives points.
the company gym. Today, the system Manuel does not want to compare with
recommends Manny to go for a short his co-workers, but likes to see that he
walk and then do some stretching received more points than last week.
exercises. His smartwatch monitors
whether Manny went for a walk and
Page 21 of 124
checks how relaxed he is using his heart Before he goes to sleep, he charges the
rate. He receives points for wearing the smartphone and smartwatch.
BIONIC system and following advices,
alone or with his fellow workers.
Compared to the other workers using
the BIONIC system, he is doing really
well and he is on his way to receive the
employee of the month award. Before
he goes to sleep, he charges the
smartphone and smartwatch.
Troubleshooting Sometimes, Manny is not sure how the Sometimes, Manuel is not sure how the
system works. In that case, there is a system works. In that case, there is a
video and tutorial available that Manny video and tutorial available that Manuel
can access whenever he wants. For can access whenever he wants. For
specific questions or technical specific questions or technical
problems, Manny can consult the help problems, Manuel can consult the help
function in the app, or the OHS function in the app, or the OHS
specialist at work (who can contact specialist at work (who can contact
technical support if needed). technical support if needed).
Exit session After three weeks, Manny visits the After three weeks, Manuel visits the
OHS specialist to hand in the BIONIC OHS specialist to hand in the BIONIC
clothes and the smartwatch. Manny clothes and the smartwatch. Manuel
found the BIONIC system helpful. He is found the BIONIC system helpful. He is
now well aware about his workload and now well aware about his workload and
that he could improve this by some that he could improve this by some
simple changes in his handling tasks. In simple changes in his handling tasks. In
addition, he performed specific addition, he performed specific
strengthening exercises and followed strengthening exercises and followed
the recommendation to be more the recommendation to be more
physically active in his free time. He physically active in his free time. He
now helps his wife in the vineyard, now goes shopping with his wife, which
which he enjoys. Above all, he he enjoys. Above all, he experiences
experiences less back problems and less back problems and feels more
feels more energetic. energetic.
Doctor Manny has received some feedback Manuel had scheduled a meeting with
involvement from the company doctor while he was his GP after the exit session. He brings
using the BIONIC system. The doctor an overview of the processed BIONIC
was able to help Manny in achieving his data with him. Together they look at the
goals and he used the processed group data and the GP sees Manuel has
data to advice about workplace design. reduced his back pain with simple
After the exit session, Manny visits the changes. Manuel indicates he will try to
company doctor to discuss his progress maintain this behavior and tells the GP
and the changes he had made. After a
month the company doctor schedules
Page 22 of 124
an evaluation session and Manny tells that he will only visit again in the case of
the doctor he was really happy that he a return of his back pain.
got to use the BIONIC system and that
The manager at work can see
he still feels much better. The doctor at
anonymous grouped data to get
work can see anonymous grouped data
recommendations about problems at
to get recommendations about
the construction site and how to
problems in the factory and how to
improve the site and prevent new
improve the production lines and
problems.
prevent new problems.
The first outcome derived from the aforementioned use cases regarding security and privacy protection
in the BIONIC systems are the following:
• The user logs into the system following a predefined authentication process along with the
company’s administrator.
• The worker uses a mobile app on his/her device.
• The user profile contains personal identifiable information along with medical data.
• Two photographs of the worker’s body morphology are taken for specific measures (segment
length, etc.) which is necessary to personalize the BIONIC system. The morphology is entered
in the profile and the pictures are deleted.
• In the settings menu, the worker has given permission to the company doctor to share his
processed data and progress
• While the worker is working, the system measures posture, movements, handling of loads and
fatigue (using IMUs in the BIONIC clothes a heart rate sensor in the smartwatch, and pressure
sensor insoles). During his /her breaks, the worker enters how he/she has been feeling in the
smartphone application/smartwatch (ESM). On the smartwatch, the worker can easily see/feel
at a glance how he/she is doing of if there are risky situations, as he/she receives personal real-
time alerts.
• The processed data collected from the worker and processed by the AI chip is sent to the cloud,
unless the worker indicates otherwise
• At home the worker a lighter version of the BIONIC system called the light BSN, consisting of
the smartwatch (heart rate, PA), some IMU sensors and smartphone app (PA, fatigue, ESM).
• The activities the worker is performing at home are stored locally on his/her phone. As soon as
the worker is back at work, the data is transferred automatically and wirelessly to the cloud.
This data from the BIONIC light outside working hours is not available to doctors, unless stated
by the worker otherwise.
• The doctor at work can see anonymous grouped data to get recommendations about problems
in the factory and how to improve the production lines and prevent new problems.
Page 23 of 124
3 PRIVACY AND DATA PROTECTION FRAMEWORK
3.1 INTRODUCTION
3.1.1 The emerge of eHealth and mHealth Systems
The medical developments and the rapid changes in the Europe demographics are increasing promptly
the average age of European citizens. These changes pose several challenges for EU future and require
urgent policy responses in order for EU to organize appropriate healthcare solutions addressing to a
growing number of individuals (Milutinovic & De Decker, 2016). This necessity is leading to a broader
enhancement and application of Information and Communication Technology (ICT) within healthcare
systems, emerging the establishment of the eHealth systems, where services and tools, based on ICT,
can improve prevention, diagnosis, treatment and monitoring (WHO, 2015; EU, EU-eHealth Policy,
2015), as wells as the healthcare-related data management and exchange (Esposito et al., 2017). What
is of major importance is that the eHealth systems, which are developing, aim to help citizens to manage
their health issues and maintain health mainly outside the traditional healthcare services context,
promoting in this way heath literacy, disease prevention, integrated care, and self-management
(Drosatos et al., 2016).
Plenty of research approaches in the domain of eHealth systems put special emphasis on the design of
remote health-monitoring systems and equipment (Chib & Lin, 2018; Milutinovic & De Decker, 2016;
Soceanu et al., 2015), leading medical and public health practice to a large scale adoption of mobile
medicine/mHealth (Marcolino et al., 2018). mHealth is supported by mobile devices, such as mobile
phones, patient monitoring devices, personal digital assistants and other wireless devices that provide
remote access to health services and users. Especially, body-worn monitoring devices and wireless
medical sensor networks are on emerge (Solomon & Elias, 2018; Milutinovic & De Decker, 2016).
Wireless medical sensor networks are considered of major impact on e-healthcare (Almarashdeh et al.,
2018), providing plenty of benefits such as ease of use, reduced risk of infection, reduced risk of failure,
reduced patient discomfort, enhancing of mobility and low cost of care delivery, while allowing the data
of a patient’s vital body parameters to be collected by wearable or implantable biosensors, such as heart
rate monitors, pulse oximeters, spirometers and blood pressure monitors (Solomon & Elias, 2018).
3.1.2 Privacy issues within eHealth

However, the wide prevalence and utilization of mobile medical devices in the area of eHealth, collecting
health data about individuals and performing monitoring and managing of health-related information,
raises serious challenges for the eHealth systems in order to support effectively privacy protection of
individuals’ personal data and access control (Milutinovic & De Decker, 2016; Soceanu et al., 2015;
Smart et al., 2014).
Considering that health information is a particularly sensitive subset of personal information,

accompanied with plenty ethical considerations, privacy is established as one of the main requirements
of eHealth area (Li, 2018). Indicatively, regarding privacy on eHealth area, OECD (2011) emphasizes on
the principles of a) security safeguards in order for the individuals’ personal data to be protected by
reasonable security, b) openness and purpose specification in order for the data collectors to specify
the main purpose of their collection, use and identity, c) limited collection and use of personal data so
as not to be disclosed, available or otherwise used rather than the specified purposes and d) the
individual participation principle, by which individuals’ rights concern on the gaining, by the data
controller, confirmation for having relating data to them, on receiving the communicated data in a
Page 24 of 124
reasonable time and manner and in an intelligible form, on reasoning if the request is denied, as well
as on erasing, rectifying, completing or amending their data.
Since within eHealth there are multiple collaborating parties coming from a diverse range of authorities
under different managements, privacy concerns derive from the sensitivity of the data that the
applications access, handle, store, use and from how/with who it is shared, indicating highly numbered
security weaknesses and privacy threats (Edemacu et al. 2019; Wagner et al., 2016). In this regard,
Omoogun et al., (2017) support that different sensors used for monitoring within mHealth are designed
without taking into consideration security and privacy aspects and therefore are vulnerable to
numerous types of attacks, or subjects to data leaks. Edemacu et al. (2019), emphasizing on cloud
eHealth systems, summarize the emerging privacy challenges in two large categories: a) loss of control
over the out-sourced data due to several privacy breach threats, such as malicious insiders, data loss
and breaches and insecure interfaces and applications and b) virtualization issues, due to attackers that
exploit the nature of cloud virtualization to learn individuals’ secret information. Therefore challenges
and threats such as eavesdropping, impersonation, data integrity, data breach and collusion pose even
more provocations for the privacy-aware management of the patients’ personal data to control
pervasive tracking and profiling (Bhuiyan et al., 2017). Additionally, users’ privacy concerns may be a
great barrier to the acceptance of the eHealth technology (Milutinovic & De Decker, 2016; Liu et al.,
2011) and in order to adopt socially acceptable health services, the security and privacy issues need to
be analyzed and addressed (Esposito et al., 2017).
Privacy is a highly complex issue within eHealth systems, which are designed to meet specific
requirements deriving from the organizations and providers who use them, as well as from the variety
of legal obligations and privacy enforcement rules that dictate protection rights of data subjects and
responsibilities of data controllers (Esposito et al., 2017). Therefore, an adequate framework is needed
in order to balance different levels of privacy regarding their data, considering, for providing the
appropriate technical solutions, not only the individuals’ requirements and needs and the health care
service providers’ and data controllers’ purposes, but also the different sets of regulations for privacy.
3.1.3 GDPR purposes and principles

Nowadays, plenty of legislations, regulations and policies define privacy protection within healthcare
systems worldwide. For instance the American Health Insurance Portability and Accountability Act
attempts to ensure the security of individuals’ medical records via a set of directions addressed to
healthcare professionals and providers, outlining specific security measures when data are used for
administrative or communication purposes (Al-Janabi et al., 2017).
At European level, the General Data Protection Regulation (GDPR), enforced in May 2018, reforms and
extends the purposes of previous measures – derived from the Directive 95/46/EC- regarding personal
data protection of the EU citizens, by the establishment of rules for the processing of personal data
concerning all EU or non-EU controllers and for individuals’ privacy rights and freedoms, imposing
compliance to all EU member-states on a sufficiently rigorous legislative framework (Sousa et al., 2018;
Lambrinoudakis, 2018).
The GDPR provides a framework for personal data protection, including seven key principles: a)
Lawfulness, fairness, and transparency, referring to easily accessible and understandable information
regarding data processing that take place under legitimate procedures, b) Purpose limitation, referring
to the use of collected data only under the specific purposes that have been specified by data
controllers, c) Data minimization, referring to the collection of specific data under a specified purpose
for a specified time period, d) Accuracy, referring to the quality of data in order to be relevant, accurate
and up-dated, including the rights of data access, rectification and erasure, e) Storage limitation,
Page 25 of 124
referring to data limited storage under the stated purposes f) Integrity and confidentiality, referring to
the appropriate technical and organizational measures that should be implemented for data protection,
as well as to the obligation of breach notification by data controllers, g) Accountability, referring to data
controllers’ obligation to implement measures that safeguard data protection and demonstrate
compliance with data protection rules (Dumas, 2018; Romanou, 2018), while other researchers
recognize also the principles of traceability and of privacy by design/ privacy by default (Rösch et al.,
2019, Mustafa et al., 2019; Tikkinen-Piri et al., 2018), data breach protection (Mustafa et al., 2019), as
well as they consider subjects’ data rights as a different principle.
According to the aforementioned principles, what is of major important is that GDPR brought significant
changes on EU citizens’ data protection and management. These changes, based on previous works
(Tikkinen-Piri et al., 2018; Lambrinoudakis, 2018; De Hert et al., 2018, Mustafa et al., 2019) have been
categorized as follows in Figure 3, indicating general categories that GDPR impacts:
Specifications on
provisions, rights and
obligations
Added
New Requirements
definitions
GDPR
Significant changes for EU
citizens data protection
New
principles
New
New rights
obligations
Figure 3. GDPR- Significant changes for EU citizens’ data protection
• New definitions for EU citizens data protection
GDPR puts the concept of risk on the top of the data protection agenda in Article 25, as a main factor
that determines the EU citizens’ data protection requirements by design and the appropriate
organizational and technical measures for the data controllers. Additionally, definitions for the concepts
of pseudonymisation, health data, genetic data, biometric data and personal data breach are provided
within Articles 1–11.
Page 26 of 124
• New principles for EU citizens data protection
The principle of individuals’ data rights are promoted on Articles 1-2 and 16-20, while traceability,
transparency of data processing, accountability, and processing principles are supported within Articles
1–11. It is of major importance that the principles of data protection by design and by default are
supported in Articles 16 and 25.
• New rights for EU citizens data protection
The right to data portability from one system to another, supported within Articles 16-20, consists a
major novelty, providing control rights to EU citizens, including the right to receive data from the data
controller in which they are provided to have access, to transmit data to another controller and to have
the personal data transmitted directly from one controller to another. In the same articles, more data
rights are given to EU citizens, such as the right to erasure, the right to data access, rectification and
restriction of processing, while, in cases of any data damage due to inadequate protection measures,
EU citizens should be reimbursed by the data controller or processor.
• New obligations for EU citizens data protection
As far as the obligations for EU citizens’ data protection concern, the novelty is focused on the fact that
the obligations not only consider the data controller, but also the data processors. In Articles 1-11 is
promoted that data controllers have to determine the purpose and the means of processing the data
and to provide transparent and easily accessible and understandable information regarding the
procedures, as well as the mechanisms in order for the citizens to exercise their rights, such as electronic
request forms, timely responses to requests or reasoning possible denials. The design of the contract
between the data processor and the data controller is crucial to increase the transparency of the
processing and allocate accountability. Additionally, data processors should be authorized by the data
controllers in cases of outsourcing activities or engaging another data processor. The obligation for the
controllers and processors to maintain a record of processing activities and to collaborate with
authorities is described in Article 30, while articles 32-34 promote processors’ obligation to notify
controller for a personal data breach and the obligation of the controllers to notify the authorities and
the respective individual for a personal data breach. Moreover, the adoption of the appropriate
technical and organizational measures for protecting the processing activities are supported in Articles
22, 23, 24 and 32, while, according to Articles 35–36 a data protection impact assessment to identify
possible unsafe processing operations should be implemented by the controllers. The principles of data
protection by design and by default are included in Articles 24-31 which should be fulfilled by the
controllers, while the appropriate safeguards should be implemented by the controllers in cases of data
transmission to a non-EU member state. The controllers and the processors established to a non-EU
member state are obligated to designate a representative in the EU according to Article 27. Finally, both
controllers and processors are obligated to designate a Data protection officer for monitoring data
operations.
• Added requirements for EU citizens data protection
By the enforcement of articles 13-15, new information are required for citizens’ rights, such as
information for data access and processing, as well as for the data controllers and data transferring to
Page 27 of 124
a non-EU member state or international organizations, while in Articles 44-49 new terms and
mechanisms for transferring data are defined, such as approved codes of conduct and approved
certifications. What is more, as far as minors’ data concern, a provided authorization by their guardian
is needed, according to the Articles 1-11.
• Specifications on provisions, rights and obligations for EU citizens data protection
The conditions for consent and lawful data processing are clarified within Articles 1–11, while in Articles
32–34 it is specified that data processors are obligated to provide security measures as well. It is of
major importance that in Articles 21-22 the right to object to personal data processing has to be
presented separately from any other information, while it has been clarified that individuals should not
take any decision based on automated processing, but only based on their stated consent. In Articles
35–36 it is clearly presented that data controllers should cooperate with authorities, only if the data
protection impact assessment indicates a high risk related to the data processing or if the supervisory
authority judges it necessary. Additionally, clarifications regarding liability in cases of damage control
for both data controllers and processors, considering joint controllers and joint processors as well, are
provided in Articles 77–84. In these cases, EU citizens have the right to a judicial remedy, while the
bodies, organizations and associations that manage these issues have been also specified.
3.1.4 Compliance to GDPR

Therefore, during the GDPR enforcement, it is essential, in order for organizations to be complied, to
fully understand the emerging issues, as well as the qualitative aspects of GDPR with respect to real
systems and the mapping of organizational data flow (Sirur, Nurse & Webb, 2018). In this regard,
previous literature demonstrates respective developing frameworks in order for personal data
collecting companies (Tikkinen-Piri et al., 2018) and Data Processors and Data Controllers
(Lambrinoudakis, 2018) to achieve compliance with the Regulation. Tikkinen-Piri’s et al., study (2018)
presented twelve aspects of the implications of the changes for data protection deriving from GDPR,
focusing on individuals’ data rights and on companies’ obligations. These aspects namely are: Specifying
data needs and usage, Considering conditions for data processing in international context, Building
privacy through data protection by design and default, Demonstrating compliance with GDPR
requirements, Developing processes to deal with data breaches, Reckoning with sanctions for non-
compliance, Designating a Data Protection Officer, Providing information to data subjects, Obtaining
consent for personal data usage, Ensuring individuals’ right to be forgotten, Ensuring individuals’ right
to data portability and Maintaining documentation.
Lambrinoudakis (2018) proposed ten steps in order for the Data Processors and Data Controllers
compliance with the requirements of the GDPR to be facilitated, focusing thus on privacy principles,
policies and mechanisms and putting on the edge the Data Protection Impact Assessment. The proposed
steps are as following: Awareness – Readiness of the Organization, Maintain a Record of Processing
Activities, Designate a Data Protection Officer, Consent, Privacy -by Design and -by Default, Protection
(security) of Processing – Risk Management / Data Protection Impact Assessment (DPIA), Data
Protection Policy, Data Breaches, Organizations Acting in Several EU Member States, Transferring Data
to non EU countries. Hence, it is noteworthy that both of the frameworks include the new principle
introduced by GDPR, this of Privacy by design.
Page 28 of 124
3.1.5 Privacy by Design Schemes under GDPR

Privacy by Design, as it was supported by Cavoukian (2012), has been incorporated into the GDPR and
it is considered to be the most appropriate approach for meeting the privacy and data protection
expectations to a large scale, since it offers realistic solutions in order for legal requirements to be
combined with the technical ones (Romanou, 2018). In this regard, the data controllers and processors
are obligated to appropriate technical and organizational measures and procedures to ensure the
protection of the data subjects’ rights and to be compliant with data protection principles
(Lambrinoudakis, 2018). As Tikkinen-Piri et al. (2018) support, data protection by design should be
managed after the specification of the processing purposes and during the processing itself. The
controller is obligated to ensure the security of the system, as well as to enhance Protection Impact
Assessment into the architecture of the system in order to safeguard adequately by default individuals’
rights regarding their data. Hence, the proposed privacy principles by Cavoukian (2012) have been under
criticism regarding its difficulties to be implemented into the system requirements (Huth, 2018;
Rubinstein & Good, 2013). Therefore, the stated necessity to embed the technological aspects of privacy
within the regulatory field (Martin & Kung, 2018) and to bridge GDPR privacy regulations with technical
solutions, is even more emerged, in order for privacy engineering practice to confront more easily the
privacy concerns and the compliance to the Regulation (Antignac, T., Scandariato, R., & Schneider,
2018).
To address that need, Rösch et al., (2019), aiming at translating existing GDPR requirements into
technical solution templates for compliant services, defined a catalogue of three types of privacy control
patterns, namely: a) general privacy control patterns, b) patterns that impact on the data subjects’ rights
and c) patterns regarding data controllers and processors’ obligations. Although authors support that
the proposed patterns provide generally applicable privacy guidelines, it is important to note that their
work focused only on the following specific GDPR principles, Transparency and Traceability, Purpose
Limitation, Data Minimization, Accuracy and Storage Limitation, since the principles of Lawfulness,
Fairness, Integrity and Confidentiality and Accountability are considered not to be fulfilled by technical
measures in a manageable time limit.
Antignac, Scandariato & Schneider (2018) presented an approach based on model transformations,
aiming to enable a more constructive approach to privacy by design under the principles of GDPR.
Although, their work consists an interesting approach to bridge privacy legal and technical field, it
focuses only on limited requirements, such as purpose limitation, or accountability of the data controller
and consequently it presents specific technical privacy properties. In this sense, Huth (2018) supports
that the need of holistic privacy patterns is emerged in order for the systems to achieve compliance
with the new GDPR regulation, while even the notable privacy approaches, such as LINDDUN, a risk-
based method for modelling privacy threats in order to support software developers in identifying and
addressing privacy threats early during software development, should be combined with other goal-
oriented approaches so as to be effective.
Palmirani et al. (2018) introduced an interesting privacy ontology that models the GDPR main
conceptual cores as following: data types and documents, agents and roles, processing purposes, legal
bases, processing operations, and deontic operations for modelling rights and duties, focusing on the
analysis of deontic operators in order to manage the checking of compliance with the GDPR obligations.
However, the study hasn’t yet achieved to integrate the different levels of semantic representation for
multiple goals and the analysis was restricted only to the Right to Data Portability.
Finally, the current EU project PDP4E (Martin & Kung, 2018) aims to integrate data protection
approaches such as LINDDUN, PRIPARE and PROPAN into systems engineering methodologies and
Page 29 of 124
process models, specializing them to operationalize GDPR compliance. Although, authors recognize the
impact of goal-driven approaches, they focus mainly on risk-based approaches as LINDDUN and
PROPAN, a threat identification method, as well as on PRIPARE methodology, derived from a previous
EU project (Notario et al., 2015), which has combined articulations of risk-based methods and privacy
by design principles for implementing privacy in practice. Therefore no one pure goal- oriented
methodology is considered, despite the fact that GDPR is considered as a purpose-oriented approach
(Huth, 2018).
3.1.6 Security and Privacy requirements within eHealth systems

As it was mentioned in previous section, GDPR provides new definitions regarding individuals’ data.
Specifically, as far as health/medical data concerns, in GDPR (Article 4-15) is defined as the “personal
data related to the physical or mental health of a natural person, including the provision of health care
services, which reveal information about his or her health status”. Additionally it is considered to be of
sensitive ones according to the Article 8 paragraph 1 of the Directive 95/46/EC and as a special category
of personal data according to GDPR (Article 9). Therefore, special emphasis, as well as the explicit
consent of data subjects, is required when processing them. As Romanou (2018) argues, the applying
of the principles of privacy by design, in order to build security and privacy into the systems, could be a
solution to the privacy concerns regarding e-health data.
Hence, despite the importance of privacy protection of health/medical data within e-Health area, which
has been recognized in a number of works (Edemacu et al. 2019; Liu, 2018; Wagner et al., 2016; Soceanu
et al., 2015; Smart et al., 2014), not many existing researches, to our best knowledge, approach it from
the outset of the design or take into consideration the necessity of compliance with new GDPR
requirements. Privacy needs to be considered during systems design and implementations (Sousa et al.,
2018); otherwise as Milutinovic & De Decker (2016) support, plenty of limitations are posed on the
system’s deployment, leading to a not adequate enough data protection solution for the users.
Additionally, literature (Iwaya et al., 2018) highlights that previous research mainly focuses on the
security issues and especially on cryptographic techniques (e.g. Solomon & Elias, 2018 study) that
perform client-side encryption of data to protect against untrusted service providers, solving
fragmentary some aspects within mHealth, while privacy engineering in this area is lacking.
Milutinovic & De Decker (2016:53) have presented a list with the privacy requirements that an eHealth
system should fulfill in order to be compliant with the legal and ethical requisites and gain a wider
acceptance as following: a) personal and recognizable information should be protected by strict access
control policies, b) non-medical professionals should not access to patients’ information, excluding
authorized guardians, c) data access should be logged securely, so that later auditing is enabled and d)
flexible control access policies should be revoked or expanded.
From a technical aspect, Sawand & Khan (2017:534) propose that eHealth monitoring systems should
fulfill the following security requirements: a) Trusted Authority, which generates public and secret key
parameters, is responsible for the issuing keys, granting as well differential access rights to the patients’
based on their attributes and roles, b) cloud service provider, in order to provide secure communication
mechanisms, as well secure data storage, processing and retrieval according to the access rights of the
requesters, c) registered user, referring to the patients’ registration to the trusted authority in order to
define their data access and the attributes based on specific access policy and d) data access requester,
referring to a doctor, a pharmacist, a researcher and a health care service, whose access rights and are
defined by the patient who use the eHealth monitoring system.
Pirbhulal et al. (2019:385-386) suggest a more analytic context regarding remote healthcare systems,
including not only security, but also privacy requirements as follows: a) data confidentiality, in order to
Page 30 of 124
prevent any disclosure during any data transmission, b) data integrity, in order to protect original data
from external attacks, c) data availability, in order for the data to be available to legitimate and
authenticated nodes/users, d) data freshness, ensuring that data is updated and no one authorized or
not can replay old data, e) scalability, in order to reduce latency and control computational and storing
overheads and g) secure key distribution, in order to allow encryption and decryption operations for
accomplishing the estimated security and confidentiality.
As the previous work, the study of Al-Janabi et al. (2017:117-118), as far as the safety of Wireless Body
Area Network systems concern, supports the data confidentiality, the data integrity, data freshness and
the secure management requirements, but it also maintains a) the availability of the network, in order
to provide at all the times access to patients’ information both to healthcare professionals and patients,
e.g. in case of an emergency health issue, b) data authentication, by which the applications should be
capable to verify that the information is sent from a known trust center, c) dependability, referring to
the systems’ reliability, since data errors may lead to health-threating issues, d) secure localization, in
order to prevent attackers to transmit improper details, such as fake signals about the patient’s location,
e) accountability, in order for the individuals’ personal information to be secured, f) flexibility, referring
to the individuals’ flexibility of designating the control of their medical data and g) privacy rules and
compliance requirement, referring to the need to secure private health information by setting privacy
measures, such as rules/polices regarding the right to access to patients’ sensitive data, since several
regulations are enlisted for health care services.
In this regard, ambitious current approaches, such as the study of Luo et al. (2018), which developed a
framework called PrivacyProtector to preserve the privacy of patients’ personal data in IoT-based
healthcare applications by presenting a secret sharing scheme, which devises the patients’ data and
stores it in several cloud servers for optimizing the secret share size and supporting exact-share repairs,
while still keeping the advantages of the previous scheme, or previous studies (Alagar, Periyasamy &
Wan, 2017; Alibasa et al., 2017), focusing on the security and privacy frameworks for m-health
applications that provide users with more control regarding the use of their sensitive health data within
them, are not taking into consideration legal aspects of privacy that are mandatory for eHealth
environments.
Especially, as far as compliance with GDPR concerns, few researches until now consider the new
requirements. Sousa et al., (2018), focused their study on openEHR, a standard that embodies many
principles of secure software for electronic health record, and provided a list of requirements for a
Hospital Information Systems compliant with GDPR, in order to examine to what extent the openEHR
may be a solution for the compliance to GDPR. Although, matches were found, the results showed that
the related to the organizational processes GDPR requirements, hardly could be met by any EHR
specification standard.
Iwaya’s et al., (2018: 46) study on mobile health data collection systems that have been used by
community health workers, provides a list with specific privacy recommendations associated with the
privacy principles and challenges emerged from the systems under the GDPR. This includes: a)
Transparency-enhancing tools, guidelines for purpose specification, fine-grained access control,
anonymization and pseudonymization, data validation and integrity and automated data deletion
measures for the principle of Data Quality within mHealth, which refers to the process of transparent
data, the purpose specification, the data minimization, the data accuracy and integrity and the data
retention, b) Obtaining informed consent and check validity of consent measures for the principle of
Legitimate Process, which refers to a legitimate data processing of sensitive data that takes into
consideration other relevant legal basis for using personal data, c) Accurate, up-to-date, easily found
Page 31 of 124
and understandable information about data controller, purpose, recipients measures for the principle
of Information Right of Data Subject, d) TETs for individualized information (e.g., privacy dashboards)
and timely response to data subject’s information requests and rectifications for the principle of Access
Right of Data Subject, e) Provision of interfaces for objections and timely responses measures for the
principle of Data Subject’s Right to Object, f) Authentication and authorization, secure communication
and storage and logging measures for the principle of Security of Data, which refers to personal
information confidentiality, integrity and availability and the detection and communication of personal
data breaches and g) Compliance with notification requirements and logging measures for the principal
of Accountability, which refers to the implementation of safeguard data protection and compliance with
data protection provisions to subjects, general public and supervisory authorities.
Finally, Mustafa et al. (2019), under the EU project WELCOME, studied the privacy of the mHealth
applications for patients suffering from Chronic Obstructive Pulmonary Disease, and proposed the
following privacy requirements within the context of GDPR: a) data patients’ right to access and
modification or erase by the applications in any case of inaccurate measurement, b) patients’ right to
information for the collected data by the applications and the time period of processing, c) limitation of
collected data in accordance to the functionality of the applications in combination with the respective
permissions, d) patients’ fully awareness of the security measures regarding data storage or transmit to
other third parties, e) patients’ right to information regarding the risk and benefits of an m-health
application, g) the prohibition of using collected data for marketing or profiling purposes, stated on an
informed medical consent, h) appropriate security mechanisms for mobile devices, providing access
only to authorized users with the proper authentication, i) access controls in order for authorized users
and mobile devices to be authenticate, k) integrity of the medical data provided by the applications, l)
proper security mechanisms for data storage. However, this interesting approach focuses only on a
specific target group of patients, excluding larger or healthier target groups in which m-health
applications are also addressed.
3.1.7 Privacy Safeguard (PriS) under GDPR

GDPR, as a legal approach, in order to fulfil its own principles and criteria for protecting privacy and
personal data in practice, has not only to rely on privacy policies, but also to come along with technical
mindsets, measures and solutions. Taking into consideration that GDPR a) imposes the requirements
for a data protection impact assessment, in order to determine whether the data processing operations
involve a risk or a high risk, before the implementation of a privacy methodology (Lambrinoudakis,
2018), b) is a purpose-oriented approach itself (Huth, 2018) and c) promotes the principle of Privacy by
Design in order to ensure that the protection of users’ privacy is a basic parameter in the early stages
of each project and throughout its life cycle (Romanou, 2018), it is arguable to maintain that a Privacy
by Design, goal-oriented privacy methodology could effectively support the implementation of the
privacy technical prerequisites that the legal framework poses itself.
With respect to this and taking into account that Privacy Safeguard-PriS (Kalloniatis et al., 2008), a goal-
driven Privacy by Design engineering methodology, was considered as effective in Robol, Salnitri &
Giorgini’s (2017) study regarding GDPR-compliant socio-technical systems, which lacking thus in
incorporating legal aspects, we provide the ground for PriS to be implemented, by making provision for
the legal concepts that GDPR has imposed. To address that, we present in the following figure the
connections between GDPR approach and PriS methodology in a high level, while subsequently a table
matching the concepts of the seven GDPR seven key data protection principles and the PriS privacy
requirements concepts is demonstrated.
Page 32 of 124
GDPR APPROACH
PriS METHODOLOGY
-PRIVACY BY DESIGN
- GOAL-DRIVEN
APPROACHES
-MATCHING
PRINCIPLES/REQUIREMENTS
Figure 4. Associating GDPR approach with PriS Methodology
Privacy Safeguard (PriS) incorporates privacy requirements into the system design process. The
methodology PriS aims to cover the gap between system design and implementation phase. This is
achieved through the modelling of organisational goals that express the intentional objectives that
control and govern its operation, the processes, that collaboratively operationalise organisational goals
and the software systems that support the above processes. PriS considers privacy requirements as
organisational goals (privacy goals), which constraint the causal transformation of organisational goals
into processes, and through the use of privacy-process patterns describe the impact of privacy goals to
the affected organisational processes. In particular, eight types of privacy goals are recognised, namely:
Authentication, Authorisation, Identification, Anonymity, Pseudonymity, Unlinkability, Data Protection
and Unobservability. At first, PriS was designed to support traditional privacy-aware information
systems. Thus, cloud computing environments introduced a number of new privacy related concepts,
leading to an extended version of PriS (Kalloniatis, 2017;2015) that provides a new set of privacy
requirements along with the ones already stated, namely, undetectability, isolation, provenanceability,
traceability, interveanability and accountability.
The first two requirements, Authorization and Identification, are mainly security requirements, but they
are included in the method due to their key role in the privacy protection. The Anonymity concerns the
ability of subjects to be unidentifiable by other subjects, while Pseudonimity is referring to subjects’
ability to use pseudonymous in order to ensure their anonymity. The Unlinkability is achieved when a
third party cannot link the relationship between subjects, actions, messages, while Undetectability
concerns the existence of a component that cannot be detected by a third party. The Unobservability is
reffering to the ability to hide the actions between subjects, and in particular it is satisfied if a system
sufficiently realises undetectability among the respective assets and anonymity of the users accessing
them, indicating an indirectly realisation through of the two previous concepts. The requirements of
isolation, provenanceability, traceability, interveanability and accountability are related to data
protection of the users or the systems over the cloud and therefore, they are grouped under the Data
Protection requirement.
The next step is the modelling of the privacy-related organisational processes. These processes aim to
support the selection of the system architecture that best satisfies them. Therefore, PriS provides an
Page 33 of 124
integrated way-of-working from high-level organisational needs to the IT systems that realise those
(Kalloniatis et al., 2008).
As it was aforementioned, GDPR aims a) to promote data collecting and processing organisations’ and
companies’ work, by introducing specific rules and requirements as a primary goal of the organizations,
as well as by providing direct instructions for the implementation of data protection, dealing thus with
several complex aspects, such as company-level awareness raising, nature – scope - context and
purposes of processing, adoption of both organizational and technological data protection processes
and measures at the start of a project, cost of implementing the protection measures and
documentation of processing operations (Tikkinen-Piri et al., 2018; Lambrinoudakis, 2018) and b) to
provide EU citizens with further control on their personal data, while minimizing the threats against
their data rights and freedoms (Doumas, 2018; Lambrinoudakis, 2018). Therefore, the conceptual
association with PriS methodology is more than clear, since PriS promotes a set of expressions based on
which the whole processes of an organization are considered, starting from the goal level and leading
to the selection of the appropriate implementation techniques.
Table 2. Matching GDPR privacy principles with PriS privacy requirements
PriS Privacy Requirements
Data Protection
Unobservability
Undetectability
Authentication
Pseudonymity
Authorisation
Identification
GDPR privacy Unlinkability

Anonymity
principles
Lawfulness, √
fairness, and √ √ √ √ √ √ √ √
transparency
Purpose √ √
√ √ √
limitation
Data √ √
√ √ √
minimization
Accuracy √ √ √ √ √ √ √ √ √
Storage √ √
√ √ √ √
limitation
Integrity and √ √ √ √ √ √ √ √ √
confidentiality
Accountability √ √ √ √ √ √ √ √ √
Based on the fact that the two approaches share a common conceptual ground, it is interesting to
identify the associations between more specific concepts, such as GDPR principles, as the key concepts
for its enforcement, and PriS Privacy Requirements, as the key concepts for the methodology to be
implemented. Therefore, Table 1 represents the analysis following by matching the GDPR privacy
principles with the PriS privacy requirements.
The principal of Lawfulness, Fairness, and Transparency concerns all the legitimate procedures, by which
individuals’ data should be collected and processing, as well as the individuals’ right to be properly
informed for any procedure. Consequently, this principle is matching with all PriS requirements,
Page 34 of 124
enabling data collecting and processing organizations to set primary privacy purposes and providing
individuals their fundamental privacy rights from a technical aspect.
The principal of Purpose limitation, concerning the use of collected data only under a specific purpose
designated by the data controller is associating with the requirements of data protection, anonymity,
undetectability, unlinkability and unobservability, supporting data collecting and processing
organizations to adopt appropriate technical and organizational measures, as well as individuals’ data
freedoms.
The principal of Data minimization, referring to the collected data only under a specific purpose for a
specified time period, matches with the requirements of anonymity, data protection, anonymity,
undetectability, unlinkability and unobservability, posing suitable measures for the organizations, while
supporting individuals’ data rights.
The principal of accuracy, concerning the quality of data and including individuals’ rights on data access,
rectification and erasure, is also associated with all with all PriS requirements, providing ground for both
organizations and individuals to protect their rights and data properly.
The principle of storage limitation, referring to data limited storage under the stated purposes, is
matching with the following requirements, authorization data protection, anonymity, undetectability,
unlinkability and unobservability, providing data controlling and processing organizations the technical
measures to ensure the storage of personal data in appropriate ways, while promoting individuals in
appropriate ways.
The principles of Integrity & confidentiality and Accountability, concerning respectively the appropriate
data protection technical and organizational measures and data controllers’ obligation to implement
measures that safeguard data protection and demonstrate compliance with data protection rules, are
also matching with all PriS requirements directly and indirectly, facilitating the organizations to develop
and implement the appropriate processes in order for individuals data to be protected.
Acknowledging that previous analysis is subjected under plenty limitations, the next step concerns the
development of a conceptual model in order to examine the relationship between GDPR privacy
principles with PriS privacy requirements more thoroughly, aiming, beyond the positive associations, to
identify whether GDPR privacy principles conflict with privacy requirements and if so, which ones.
Through this examination, software developers will be able to consider in a more understandable way
the appropriate technical solutions that satisfy GDPR.
3.2 DESCRIPTION OF THE FRAMEWORK

BIONIC proposes a flexible and efficient GDPR Compliant Personal Data Management methodology in
order to ensure the security, safety and privacy aspects of using holistic and unobtrusive Body Sensor
Networks on ageing workforce, which is going to employ the system in their daily tasks. The Framework
ensures that GDPR principles, such as purpose limitation, data minimization, accuracy, accountability,
the lawfulness of processing, the user consent, are fully satisfied. In this regard, the medical wearable
applications will respect all the data owners’ rights (ageing workers), such as their rights to object to the
storage/processing of their information, their right to be forgotten, their right to restriction of
processing, while the obligations of the intermediate users, such as occupational health professionals,
production managers, and in general all the professional profiles that manage the system and
potentially exploit all the data generated within BIONIC are specified. Finally, all necessary technical,
organizational and procedural measures for the satisfaction of the eliciting security and privacy
Page 35 of 124
requirements are considered and thus enhancing confidence and trust among all stakeholders. It
comprises of the following four stages, pictured in Figure 5:
•Purposes of Processing
Stage 1: •Data categories
Personal Data •Data Flows
handling
processes
elicitation
Stage 2:
Compliance • Determine the existing Compliance
level
Level on GDPR
• Elicit organisational and procedural
requirements
requiremetns
•Risk Analysis
Stage 3: Security
•Threat/Attack modelling
and Privacy
•Privacy by design approach
requirements
elicitation •Elicitation of technical
security and privacy
requirements
Stage 4: Impact
estimation from
•DPIA
Security/Privacy
violation incidents •Risk Factors
Figure 5. GDPR Compliant Personal Data Management Methodology
3.2.1 Stage 1: Personal Data handling processes elicitation

The purpose of this step is to define the perimeter of the Personal Data handling processes, by
capturing, reviewing and formalizing the following issues:
• The categories of the personal data processed.

• The categories of the data subjects
• The purposes of each processing activity
• The identification of high risk data processing activities
Page 36 of 124
• The legal basis of each processing activity (e.g. contract and/or consent and/or legitimate
interest and/or statutory obligation)
• The categories of recipients to whom the personal data are disclosed
• The envisaged time limits for erasure of the different categories of data – if they exist
• The existing technical and organizational measures for the protection of personal data.
To this end, a Questionnaire for Accessing GDPR Compliance is designed and implemented. The
objective of this questionnaire, addressed to BIONIC respective stakeholders, namely: Rolls-Royce
Power Systems and ACCIONA CONSTRUCCION S.A., is to identify, through a systematic procedure, the
aforementioned information for each purpose of data processing separately.
The questionnaire includes seven items, requiring open responses, regarding the following issues:
• Short Description for the purpose of processing

• Legal Basis for the purpose of processing, including the subcategories a) Law, b)User / patient
consent, c) Contract
• The data involved in serving the specific purpose of processing, including the subcategories a)
General Data, b) Personal Data, c) Special categories of Personal Data
• The necessity of the involved data for serving the specific purpose of processing
• The sources of collected data
• The transmission of personal data to third parties
• The processing of automated decision-making, including profiling
Therefore its main output concerns the listing of the Purposes of Processing and the Personal Data
Categories.
INPUT • List of Purposes of

processing
Identifying Personal Data • Questionnaire for
Accessing GDPR • List of Data
Categories
handling processes Compliance
OUTPUT
Figure 6. Output of Stage 1
3.2.2 Stage 2: Compliance Level on GDPR requirements

During the second stage, it is essential to map the organizational context following the results of stage
1. Therefore, when the above list of information has been compiled, the processing of each personal
data category is being reviewed against the GDPR requirements to deduce the existing compliance level,
through a GDPR gap analysis. Topics that are examined are presented indicatively as following:
• lawfulness, fairness and transparency of the personal data processing

• the processing purpose limitation, the data minimization,
• the consent of the data subjects,
• the personal data storage limitation
Page 37 of 124
• the measures for personal data protection

• integrity and confidentiality
• The readiness of the involved stakeholders to respond to the data subjects’ rights’ is examined,
such as the ‘right of access’, the ‘right to rectification’, the ‘right to be forgotten’, the right to
restriction of processing’, the ‘right to data portability’, the ‘right to object’.
• Information to be provided where personal data have not been obtained from the data subject
• Automated individual decision-making, including profiling
• Data protection by design and by default
• Joint controllers
• Security of processing
• Processing under the authority of the controller or processor
• Tasks of the data protection officer
• Transfers on the basis of an adequacy decision
Moreover, the readiness of the organization to respond to the data subjects’ rights’ will be examined.
Indicatively the ‘right of access’ , the ‘right to rectification’, the ‘right to be forgotten’, the ‘right to
restriction of processing’, the ‘right to data portability’, ‘right to object’.
Indicative activities that will be performed during the gap analysis include:
• Review of legal basis on which the organization processes Personal Information.

• Review the necessary retention periods per category of Personal Information, for various
reasons such as for compliance with a legal obligation, for inquiries of auditing authorities, for
legal claims, for public interest etc.
• Review of Privacy Notices.
• Review of the legal basis for marketing services.
• Legal review of all defined internal Personal Information Protection Policies and Procedures.
• Legal Review of sample employment contracts and updating with necessary legal language to
allow the processing of employees Personal Information for legitimate business purposes.
• Review of standard consent forms used to collect and record data subject consent for the
processing of Personal Information.
• Legal review of standard Intra- and Third-Party contracts, Procurement contracts and Supply
Contracts to identify any contractual gaps in relation to Data Protection relevant clauses. If no
standard contracts are used, the review will cover key activities, which should at least include
all contracts related to identified high risk processing activities.
• Understand the operational policies and procedures for the IT systems
• Access the efficiency of the organization to protect the data (data protection measures)
• IT and Security Governance review
• Network architecture review
The main output of this stage concerns a Set of GDPR Compliance Requirements for each identified
purpose of Processing.
Page 38 of 124
INPUT •Set of GDPR compliance

Requiremetns
•GDPR GAP ANALYSIS •Organizational and
Compliance Level on Procedural Requirements
GDPR requirements
OUTPUT
3.2.3 Stage 3: Security and Privacy requirements elicitation

Security is protection against intended incidents, i.e. incidents that happen due to a result of deliberate
or planned act. Security concerns the protection of assets from threats, where these are categorised as
“the potential for abuse of protected assets”. Whereas, privacy concerns the protection of the assets’
owner identity from users that do not have the owner’s consent to view/process their data. Risk analysis
or equivalently Risk Assessment is the methodology where an IT infrastructure and/or interconnection
between computational devices is methodically analysed and the corresponding Security/Privacy
threats are identified as long with the specific vulnerabilities and/or potential failures may cause them.
Moreover, the goal of a security assessment, is to ensure that necessary security and privacy objectives
are integrated into the design and implementation of an architecture. A Vulnerability is defined as a
weakness, in terms of security and privacy, that exists in from a resource, an actor and/or a goal (Zhou
et al., 2015). Vulnerabilities are exploited by threats, as an attack or incident within a specific context.
A Threat represents circumstances that have the potential to cause loss; or a problem that can put in
danger the security features of the system (Mouratidis et al. 2013).
In Stage 3, a Risk analysis, identifying threats, vulnerabilities, data, is conducted in order to deduce
attack modelling and threat propagation. The need for such analysis results directly from the GDPR
principle of accountability. The analysis assists in the identification and assessment of security and
privacy risks and thus in the selection of the appropriate measures to reduce these risks and as such
reduce the potential impact of the risks on the data subjects, the risk of non-compliance, legal actions
and operational risk.
At the end, the privacy by design approach Privacy Safeguard (PriS) is applied to collect all identified
security and privacy requirements (Legal, Organizational, Technical), validating that they are indeed
expressed in a technically sound manner and ensuring that they can be implemented in the context of
the specific system. The requirements elicitation methodology supports threat, vulnerability and attack
analysis, reasoning on security and privacy requirements and modelling of the system.
Based on the analysis provided in Section 3.1.7, PriS was selected for the security and privacy modelling
of BIONIC since:
i. It consists a privacy by design method, an approach that GDPR sets on its main principles.
ii. It is one of the oldest and mostly evaluated privacy by design methodologies.
Page 39 of 124
iii. On a conceptual level, GDPR principles’ concepts are associated with PriS privacy requirements
concepts.
iv. It combines stakeholders’ needs and goal-driven modelling which is very important due to the
purpose-oriented philosophy of the Regulation.
v. It can be easily aligned with a risk-based analysis, which is also prerequisite for GDPR.
The proposed steps for implementing stage 3 can be described as follows:
Substep1: Identify System Assets and Stakeholders

The purpose of this step is to define the perimeter (boundaries) of the study. A global vision of the
components and communications between components will be clarified. At this step, the following data
will be collected and formalized:
• Essentials assets of the BIONIC system.

• Functional description of components and relations between components.
• Security issues that need to be addressed by the study.
• Assumptions made if appropriate.
• Existing security rules (law and regulation, existing rules in other studies).
• Constraints (internal or external) from BIONIC system itself.
At the end of this step, a clear vision of the components and the links between them will be formalized
that are going to be used as input for the risk analysis method according the BIONIC’s Use Cases as these
are defined in deliverable 1.3.
Substep2: Identify Potential Security and Privacy Threats and related System Vulnerabilities
The security/privacy threats and vulnerabilities affecting the BIONIC system will be studied as outcome
from a dedicated risk analysis. The threats and vulnerabilities are going to be specific for the BIONIC’s
infrastructure components.
The following activities will be performed:
• List the relevant attack methods (In collaboration with project partners - experts) against
security and privacy.
• Characterize the threat agents for each attack method retained according to their type.
• Identify the security and privacy vulnerabilities of the entities according to attack methods.
• Estimate the vulnerability level.
• Formulate the security and privacy threats.
• Assign priority in the security and privacy threats according to the probability of their
occurrence.
The list of the pertinent security and privacy threats and the type of attacks will be the main outputs of
this step.
Substep3: Security and Privacy Requirements Analysis

From the previous step, the identification of the respective threats and the attack methods that can be
deployed to the proposed system leads to the identification of the system’s vulnerabilities. At this stage,
Security and Privacy vulnerabilities detection will lead to the identification of the security and privacy
objectives, which are the way that vulnerabilities are reduced thus reducing the potential risk on the
identified entities. PriS methodology will be used as a privacy by design approach in order to analyse
from the elicited threats and vulnerabilities the security and privacy goals that will have to be fulfilled.
Page 40 of 124
The next step of the specific stage is the definition of the security and privacy requirements that basically
describe in a specific way the realization of the identified security and privacy objectives.
The following actions will be considered when identifying security and privacy requirements:
• List the security and privacy functional requirements

• Justify the adequacy of coverage of the security and privacy objectives
• Highlight any coverage flaws (residual risks) with justifications.
• Classify the Security and privacy requirements for each use case.
• Where appropriate, justify the coverage of dependencies of security and privacy requirements
The main output of this stage concerns a) a List of Threats and Attacks, b) the provision of Legal and
Organizational Measures and c) the elicitation of the appropriate security and privacy requirements.
INPUT •List of Threats and Attacks

•Legal and Organizational
•RISK ANALYSIS Requiremetns
Security and Privacy •PriS method •Appropriate security and
requirements under privacy requirements
GDPR
OUTPUT
3.2.4 Stage 4: Data Protection Impact Assessment

According to the Regulation (EC) 2016/679 of the European Parliament and of the Council of 27th April
2016 for the protection of natural persons with regard to processing of personal data and on the free
movement of such data, where a type of processing in particular using new technologies, and taking
into account the nature, scope, context and purposes of the processing, is likely to result in a high risk
to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an
assessment of the impact of the envisaged processing operations on the protection of personal data. A
single assessment may address a set of similar processing operations that present similar high risks.
Taking into account the systems’ and threats’ continuous evolution, risk management “necessitates”
the identification of appropriate controls. The processing of personal data, the hierarchy and
management of risks has to be examined in a way that optimises the cost and contributes to the most
suitable decision making, aiming at protecting personal data. Impact assessment contributes to the
application of privacy principles, in a way that the data subjects are able to preserve control of their
personal data.
Page 41 of 124
A data protection impact assessment, and hence, the criticality of data shall (in accordance with
Regulation (EC) 2016/679 of the European Parliament and of the Council) particularly be required in the
case of:
a) a systematic and extensive evaluation of personal aspects relating to natural persons which is
based on automated processing, including profiling, and on which decisions are based that
produce legal effects concerning the natural person or similarly significantly affect the natural
person (e.g., user profiling by web search activity monitoring for targeted advertising and
promotion of products and services (hotels, restaurants, etc.),
b) processing on a large scale of special categories of data referred to in Article 9(1), or of personal
data relating to criminal convictions and offences referred to in Article 10 (e.g., processing of
patients’ medical records (special category of personal data) from healthcare organisations,
including medical history, illnesses, and patient care, etc.) or
c) a systematic monitoring of a publicly accessible area on a large scale (e.g., traffic monitoring for
informing drivers of the fastest route, residence entries’ monitoring, public transport entrance,
etc.).
Moreover, the assessment shall contain, in accordance with Regulation (EC) 2016/679 of the European
Parliament and of the Council, at least:
a) a systematic description of the envisaged processing operations and the purposes of the
processing, including, where applicable, the legitimate interest pursued by the controller;
b) an assessment of the necessity and proportionality of the processing operations in relation to
the purposes;
c) an assessment of the risks to the rights and freedoms of data subjects;
d) the measures envisaged to address the risks, including safeguards, security measures and
mechanisms to ensure the protection of personal data and to demonstrate compliance with
this Regulation taking into account the rights and legitimate interests of data subjects and other
persons concerned.
This privacy impact assessment is based on a robust conceptual framework related to personal data and
data subject protection, to the processing of this data by Information Systems or non-automated means,
as well as to an impact analysis of possible incidents of personal data for the data subjects they belong
to.
Impact assessment aims at the protection of personal data, according to the definition provided by the
GDPR, during its processing, as well as the protection of elements that support their processing and are
recognised as Assets. The value of such assets is equal to the Impact brought upon by a possible violation
of individuals’ privacy. A Feared Event is the illegitimate access to personal data, unwanted modification
of personal data, as well as the data disappearance. The violation of Information Systems needs the
existence of Vulnerability and the appearance of a relevant Threat coming from a Risk source.
Summarising, we note that a Threat exploits a vulnerability of an Information System and can have as a
result an incident of data protection breach, inflicting some Impact on data subjects.
Page 42 of 124
Figure 9. Conceptual Framework of Impact Assessment
A Risk is a hypothetical scenario that describes:
• how Risk Sources (e.g., an employee bribed by a competitor)

• could exploit the vulnerabilities in personal data supporting assets (e.g., the file management
system that allows the manipulation of data)
• in a context of threats (e.g., misuse by sending emails)
• and allow feared events to occur (e.g., illegitimate access to personal data)
• on personal data (e.g., customer file)
• thus, generating potential impacts on the privacy of data subjects (e.g., unwanted solicitations,
feelings of invasion of privacy, etc.).
The following figure summarizes all the concepts above:
Page 43 of 124
Figure 10. Risks and Feared events
The risk level is estimated in terms of severity, which represents the magnitude of a risk. It essentially
depends on the prejudicial effect of the potential impacts, and likelihood, which represents the
possibility for a risk to occur. It essentially depends on the level of vulnerabilities of the supporting assets
facing threats and the level of capabilities of the risk sources to exploit them as shown below.
Figure 11. Factors used to estimate risks
In this stage a data protection impact assessment (DPIA) method will be applied in order to identify the
severity and likelihood of any possible privacy violation incidents. During this stage all security and
privacy requirements elicited in stage 3 will be evaluated in order to eliminate any possible conflicts
prior to the selection of the security and privacy countermeasures. In parallel the DPIA will assist in the
identification and assessment of privacy risks and thus in the selection of the appropriate measures to
reduce these risks and as such reduce the potential impact of the risks on the data subjects, the risk of
non-compliance, legal actions and operational risk. Then the appropriate technical countermeasures for
the satisfaction of each requirement will be identified. This information will facilitate the developers to
Page 44 of 124
select and proceed with the most suitable implementation techniques for ensuring the security
(confidentiality, integrity and availability) of the data processed, as well as the protection of the users’
privacy (user consent on data processing and data transmission, satisfaction of user rights etc.).
For conducting the DPIA it is necessary to consider both the output of stage 2 regarding the
organizational and legal requirements as they are derived from the Gap analysis as well as the output
of stage 3 regarding the technical security and privacy requirements derived from the risk/threat
analysis and the privacy by design approach.
The main output of this stage concerns a) the severity of the privacy violations incidents and b) the
likelihood of the privacy violations incidents. The following figure presents the input and output of stage
4.
INPUT •DPIA
•GDPR Compliance Requirements •Risk Factors
Impact estimation from •List of Threats and Attacks
•Legal and Organizational
Security/Privacy Requiremetns
violation incidents •Security and privacy
requirements
OUTPUT
The output of stage 4 will enable the developers to select and proceed with the most suitable
implementation techniques for ensuring the security (e.g. confidentiality, integrity and availability) of
the data processed, as well as the protection of the users’ privacy (e.g. user consent on data processing
and data transmission, satisfaction of user rights) under GDPR principles. In the following sections the
analysis of each stage is described in more detail.
Page 45 of 124
4 APPLICATION OF THE PRIVACY AND DATA PROTECTION FRAMEWORK
4.1 STAGE 1: PERSONAL DATA HANDLING PROCESSES ELICITATION

For defining the Personal Data handling processes, a Questionnaire for Accessing GDPR Compliance is
designed and implemented (see section APPENDIX A: Questionnaire for Stage 1 ). The questionnaire
was addressed to BIONIC stakeholders, namely: Rolls-Royce Power Systems and ACCIONA
CONSTRUCCION S.A., in order to identify, through a systematic procedure, the information referred to
subsection 3.2.1 for each purpose of data processing separately.
The questionnaire included seven items, requiring open responses, regarding the following issues:
• Short Description for the purpose of processing

• Legal Basis for the purpose of processing, including the subcategories a) Law, b)User / patient
consent, c) Contract
• The data involved in serving the specific purpose of processing, including the subcategories a)
General Data, b) Personal Data, c) Special categories of Personal Data
• The necessity of the involved data for serving the specific purpose of processing
• The sources of collected data
• The transmit of personal data in third parties
• The processing of automated decision-making, including profiling
Based on the project’s objectives and the replies of the end users the BIONIC consortium defined the
following two purposes of processing.
PP1: Evaluate medical data to improve employees’ health
PP2: Evaluate medical data to improve working conditions
For the first purpose of processing both end users agreed on the following set of data types that should
be collected and which are absolutely necessary for serving the specific goal. In the following table, the
categories of data along with the specific types of data for every category are presented.
Table 3. Categories of data for Purpose of Processing “Evaluate medical data to improve employees health”
Categories of Data
Data Categories Subcategory Data
1. Name
2. Last name
3. Age/Date of Birth
4. Height
5. Weight
Worker’s
6. Gender
Personal Data
Personal Data 7. Job Profile
8. User Settings
9. Work Session Task
10. Body Morphology Skeleton
11. Adaptive Settings
Kinetic 12. Carried Load
Processed 13. Vibrations
Data 14. L/R Ground Reaction Force
Page 46 of 124
Categories of Data
15. Trunk rotation

16. Trunk lateral bending
17. Trunk flexion/extension
18. Head/neck rotation
19. Head/neck lateral bending
Kinematic 20. Head/neck flexion/extension
Processed 21. Shoulder / upper arm rotation
Data 22. Shoulder / upper arm lateral bending
23. Shoulder / upper arm flexion/extension
24. Knee flexion
25. Ankle flexion
26. Hip angle
27. Position Information of measured body segments
28. Heart Rate
Physiological
29. Fatigue
Data
30. Respiratory Rate
Ergonomic 31. Ergonomic Score Computation
Tools Output 32. Alerts
33. Feeling/Mood State
Experience
34. Perceived Fatigue
Sampling
35. Perceived Pain
36. Ambient Temperature
Environmental 37. Humidity
Other data
Data 38. Noise Levels
The sources of all types of data (1-38) along with the legal basis for their collection by the BIONIC system
are presented below.
Table 4. Sources of data for Purpose of Processing “Evaluate medical data to improve employees health”
Data Sources Data from Table 3 Legal Basis
1. Worker 1-11, 33-35
2. AI Chip 12-27, 31-32 Consent
3. Sensors 28-30, 36-38
Finally it is mentioned that the data won't be transmitted to any external parties and will be stored on
a private data base on the end user’s premises when the system is ready to be deployed. During the
project’s development phases no actual worker’s data will be used and the data used will be stored on
private data bases on the partners’ premises.
Page 47 of 124
For the second purpose of processing both end users agreed on the following set of data types that
should be collected and which are absolutely necessary for serving the specific goal. In the following
table, the categories of data along with the specific types of data for every category are presented.
Table 5. Categories of data for Purpose of Processing “Evaluate medical data to improve working conditions”
Categories of Data
Worker’s Data 1. Work Session Task

Kinetic 2. Carried Load
Processed 3. Vibrations
Data 4. L/R Ground Reaction Force
5. Trunk rotation
6. Trunk lateral bending
7. Trunk flexion/extension
8. Head/neck rotation
9. Head/neck lateral bending
Kinematic 10. Head/neck flexion/extension
Personal Data Processed 11. Shoulder / upper arm rotation
Data 12. Shoulder / upper arm lateral bending
13. Shoulder / upper arm flexion/extension
14. Knee flexion
15. Ankle flexion
16. Hip angle
17. Position Information of measured body segments
18. Heart Rate
Physiological
19. Fatigue
Data
20. Respiratory Rate
Ergonomic 21. Ergonomic Score Computation
Tools Output 22. Alerts
Other data Environmental 23. Ambient Temperature
Data 24. Humidity
25. Noise Levels
The data collected for supporting purpose of processing 2 is an anonymised subset of the data collected
for purpose of processing 1, as it can be seen in the aforementioned table. Thus, there is no new source
of data, other than the BIONIC Storage platform were the data are stored as they were initially collected
and/or produced by the BIONIC components.
Finally, for the second purpose of processing the data won't be transmitted to any third party or
outsourced in any way. Since the data used for this purpose of processing will be an anonymised set of
data based on the collected data stored in the BIONIC data base for serving purpose of processing 1,
this purpose of processing has no privacy implications for the workers and the BIONIC stakeholders.
Thus, purpose of processing 2 won’t be considered in the following stages of the security and privacy
analysis.
In the following stage, the analysis of purpose of processing 1 against the GDPR requirements will be
conducted in order to identify the organisational and legal requirements that have to be fulfilled by the
BIONIC system in order to be GDPR compliant.
Page 48 of 124
4.2 STAGE 2: COMPLIANCE LEVEL ON GDPR REQUIREMENTS

4.2.1 Introduction
This section presents and analyses the findings of the Gap Analysis for the first purpose of processing
(PP1) of the BIONIC system in relation to the requirements of the General Data Protection Regulation
2016/679 (GDPR). In particular, the compliance of the BIONIC system with the requirements of each
GDPR article is examined, taking into account the required data protection policies, documentation,
security measures, etc.
This analysis considers controller’s activities which in the BIONIC case are the two end users (MTU and
ACCIONA). Table 6 describes the status of the controller’s activities for ensuring compliance with the
GDPR requirements.
Table 6: Description of the Status of Controller’s Activities for ensuring GDPR Compliance for the BIONIC system
Status of Compliance
Description
Activities
The organization has taken all necessary steps to comply with specific
IMPLEMENTED
GDPR requirements
The organization has taken part of the necessary steps to comply with
IN PROGRESS
specific GDPR requirements
The organization is not obliged to comply with specific GDPR

NOT APPLICABLE
requirements
The organization has not taken any of the necessary steps to comply
NOT IMPLEMENTED
with specific GDPR requirements
4.2.2 Gap Analysis Results

The full list of the Gap Analysis’s findings for the PP1 of the BIONIC system, in relation to the
requirements of the General Data Protection Regulation 2016/679 (GDPR), can be found in Table 10.
An overview of the findings is depicted through Table 7, Figure 13 and Figure 14.
Page 49 of 124
Table 7, below, highlights the GDPR articles requiring further attention, in terms of compliance activities (either new activities or finishing activities that are in
progress). Also, it highlights the GDPR articles for which no further action is necessary.
Table 7: Summary of the Gap Analysis findings for the PP1 of the BIONIC system in relation to the requirements of the General Data Protection Regulation 2016/679 (GDPR)
No of Articles No of
No of Articles No of Percentage (%) of
for which Compliance (%) completed
Article Category requiring Compliance completed
compliance has per Article Category Compliance
compliance Activities Compliance Activities
been achieved Activities
Principles 6 2 33,33333333 18 5 27,77777778
Rights of the data subject 11 2 18,18181818 21 7 33,33333333
Controller and processor 15 7 46,66666667 31 11 35,48387097
Transfers of personal data 6 6 100 6 6 100
Specific processing situations 2 1 50 3 2 66,66666667
Page 50 of 124
Based on Column “Compliance (%) per Article Category” of Table 7, the following diagram has been derived.
Figure 13. Compliance level (%) per Article Category for the BIONIC system
Page 51 of 124
Based on Column “Percentage (%) of completed Compliance Activities” of Table 7, the following diagram has been derived:
Figure 14. Percentage (%) of the activities completed by the Controller for ensuring compliance of the BIONIC system with the GDPR requirements
Page 52 of 124
Based on the gap analysis findings (Table 10), the overall GDPR compliance level for the BIONIC system
(Processing Activity PP1) is 45% for the total number of articles (Table 8, Figure 15).
Table 8: Overall GDPR compliance level for the BIONIC system
Articles YES NO Compliance %
40 18 22 45
Figure 15. Graphic depiction of the overall GDPR compliance level for the BIONIC system
Based on the above, it is deduced that the BIONIC controller should take additional corrective actions
in relation to its operational, organizational and technical procedures. More specifically, the controller
should proceed with the 48 pending compliance activities («IN PROGRESS» and «NOT IMPLEMENTED»)
(Table 9, Figure 16). No action is necessary for the compliance activities marked as «NOT APPLICABLE».
Table 9: Status of the Controller’s Activities for ensuring compliance of the BIONIC system with the GDPR requirements
COMPLIANCE ACTIVITIES/DEMANDS
COMPLIANCE ACTIVITIES STATUS No of ACTIVITIES PERCENTAGE
IMPLEMENTED 4 5,063291139
IN PROGRESS 10 12,65822785
NOT IMPLEMENTED 38 48,10126582
NOT APPLICABLE 27 34,17721519
TOTAL 79 100
Page 53 of 124
Figure 16. Graphic depiction of the status of the Controller’s Activities for ensuring compliance of the BIONIC system with the
GDPR requirements
Page 54 of 124
Table 10 provides the findings of the Gap Analysis for the PP1 of the BIONIC system in relation to the requirements of the General Data Protection Regulation
2016/679 (GDPR).
Table 10: Findings of the Gap Analysis for the PROCESSING ACTIVITY PP1 of the BIONIC system in relation to the requirements of the General Data Protection Regulation
Regulation's
Article's subject Compliance Activities/Demands Activities Status Compliance
Article
Conduct a DPIA
"Principles relating to processing of a) lawfulness, fairness and transparency
personal data b) purpose limitation IN PROGRESS
c) data minimisation
f) integrity and confidentiality
a) lawfulness, fairness and
transparency Data Protection Policy
NOT
Process to maintain data quality
IMPLEMENTED
Article 5 b) purpose limitation d) accuracy NO
Data Protection Policy
c) data minimisation NOT
Process for data retention period
IMPLEMENTED
e) storage limitation
d) accuracy
e) storage limitation Maintain records of processing activities IN PROGRESS
f) integrity and confidentiality" NOT

Maintain documents as a proof of compliance
IMPLEMENTED
Conduct a DPIA
IN PROGRESS
Lawfulness of processing
Article 6 Lawfulness of processing NO
Maintain documents to prove the lawfulness of NOT
processing (Law, contracts, consent forms etc) IMPLEMENTED
Page 55 of 124
Regulation's
Article
Data Protection Policy NOT

Process for acquiring data subjects' consent IMPLEMENTED
NOT APPLICABLE
Process for secondary use of personal data
Process for acquiring data subjects' consent IMPLEMENTED
Article 7 Conditions for consent Data Protection Policy NO
NOT
Process for managing/satisfying the rights of the
IMPLEMENTED
data subjects
Conditions applicable to child's Data Protection Policy
Article 8 consent in relation to information Process for acquiring childs' consent through the NOT APPLICABLE YES
society services approval of the child's parental responsibility
Conduct a DPIA
Lawfulness of processing of special categories of IN PROGRESS
personal data
Maintain documents to prove the lawfulness of

Processing of special categories of NOT
Article 9 processing of special categories of personal data NO
personal data IMPLEMENTED
(Law, contracts, consent forms etc.)
NOT
Process for acquiring and using data (including
IMPLEMENTED
special categories of personal data)
Processing of personal data relating Conduct a DPIA

Article 10 NOT APPLICABLE YES
to criminal convictions and offences Lawfulness of processing
Page 56 of 124
Regulation's
Article
Maintain documents (Law, contracts, consent forms

etc) to prove the lawfulness of processing personal NOT APPLICABLE
data relating to criminal convictions and offences
Process for acquiring and using data (including
NOT APPLICABLE
personal data relating to criminal convictions and
offences)

NOT
Process for informing data subjects about the ways
IMPLEMENTED
of processing of their data
Transparent information,
communication and modalities for NOT
Article 12 Process for managing/satisfying the rights of the NO
the exercise of the rights of the IMPLEMENTED
data subjects
data subject
NOT
Process for notifying the supervisory authority/data
IMPLEMENTED
subjects about a personal data breach

NOT
Process for informing data subjects about the ways
IMPLEMENTED
Information to be provided where
Article 13 personal data are collected from NOT NO
Process for managing/satisfying the rights of the
the data subject IMPLEMENTED
data subjects
Process for acquiring and using data IMPLEMENTED
Page 57 of 124
Regulation's
Article

NOT APPLICABLE
NOT
IMPLEMENTED
Process for informing data subjects about the ways NOT APPLICABLE
Process for managing/satisfying the rights of the NOT APPLICABLE
data subjects
Information to be provided where
Article 14 personal data have not been Data Protection Policy YES
NOT APPLICABLE
obtained from the data subject Process for acquiring and using data
NOT APPLICABLE
Process for notifying the supervisory authority/data NOT APPLICABLE
NOT
Article 15 Right of access by the data subject Process for managing/satisfying the rights of the NO
IMPLEMENTED
data subjects

NOT
Article 16 Right to rectification Process for managing/satisfying the rights of the NO
IMPLEMENTED
data subjects
Page 58 of 124
Regulation's
Article

Right to erasure (‘right to be NOT
forgotten’) IMPLEMENTED
data subjects
NOT
Article 18 Right to restriction of processing Process for managing/satisfying the rights of the NO
IMPLEMENTED
data subjects

Notification obligation regarding
Process for management / satisfaction of the rights NOT
Article 19 rectification or erasure of personal NO
of the data subjects (including process of informing IMPLEMENTED
data or restriction of processing
the subjects of changes made by the organization)
Article 20 Right to data portability Process for managing/satisfying the rights of the NOT APPLICABLE YES
data subjects
NOT
Article 21 Right to object Process for managing/satisfying the rights of the NO
IMPLEMENTED
data subjects

Automated individual decision- NOT
making, including profiling IMPLEMENTED
data subjects
Conduct a DPIA (if required) IN PROGRESS
Article 24 Responsibility of the controller NOT NO
IMPLEMENTED
Page 59 of 124
Regulation's
Article

Process for determining the obligations of NOT APPLICABLE
processors (if any)
NOT
Process for internal review/auditing of policy
IMPLEMENTED
implementation
NOT
Maintain documents as a proof of compliance
IMPLEMENTED
Conduct a DPIA (if required) IN PROGRESS
Data protection by design and by Data Protection Policy
Article 25 NOT NO
default Process for accommodating data protection by
IMPLEMENTED
design and by default specifications
As for Data Controller (Articles 24 and 25) NOT APPLICABLE
Article 26 Joint controllers Maintain documents to define the obligations as to YES

the lawfulness of data processing and satisfaction NOT APPLICABLE
of the rights of the data subjects
Representatives of controllers or
Process for immediate notification of the controller NOT
Article 27 processors not established in the NO
and the data subjects (if necessary) about a IMPLEMENTED
Union
personal data breach

Article 28 Processor Process for checking the compliance of the NOT APPLICABLE YES
processors with the obligations set by the controller
Page 60 of 124
Regulation's
Article

Process for immediate notification of the controller
NOT APPLICABLE
and the data subjects (if necessary) about a
personal data breach
Process for checking the compliance of those
Processing under the authority of
Article 29 involved (subcontractors) with the data processing NOT APPLICABLE YES
the controller or processor
with the terms that the controller or the processor
has included in their contracts
Article 30 Records of processing activities Maintain records of processing activities IN PROGRESS NO

Conduct a risk analysis study IN PROGRESS
Security measures based on the risk level (e.g.
pseudonymization, encryption, access control, IN PROGRESS
Article 32 Security of processing firewall, network intrusion detection, logs, etc.) NO
NOT
Process for Aligning Data Protection Policy with
IMPLEMENTED
Security Policy
NOT
Notification of a personal data IMPLEMENTED
Article 33 subjects about a personal data breach NO
breach to the supervisory authority
NOT
Maintain a record of incidents/breaches
IMPLEMENTED
Page 61 of 124
Regulation's
Article
Maintain the list of notifications to the supervisory

NOT
authority/data subjects about a personal data
IMPLEMENTED
breach
Maintain record/log of actions when dealing with a NOT
data breach IMPLEMENTED
NOT
IMPLEMENTED
NOT
Maintain a record of incidents/breaches
Communication of a personal data IMPLEMENTED
Article 34 NO
breach to the data subject Maintain the list of notifications to the supervisory
NOT
authority/data subjects about a personal data
IMPLEMENTED
breach
Maintain record/log of actions when dealing with a NOT
data breach IMPLEMENTED
Article 35 Data protection impact assessment Conduct a DPIA (if required) IN PROGRESS NO
Consultation of PIA's results with the Supervisory
Article 36 Prior consultation NOT APPLICABLE YES
Authority (if required)
Designation of the data protection Designation of the data protection officer (DPO) (if
Article 37 IMPLEMENTED YES
officer required)
Independence, regular communication /
Position of the data protection
Article 38 collaboration, accountability of DPO with the IMPLEMENTED YES
officer
management
Page 62 of 124
Regulation's
Article
Confirmation of non-conflict of interest of the DPO

with other duties and obligations of the IMPLEMENTED
organization
Is the DPO designated (if required) with her duties
Article 39 Tasks of the data protection officer IMPLEMENTED YES
set?
Maintain Documentation to Confirm the lawfulness
of Personal Data transfers to Third Countries or
International Organizations (eg Law, Consent forms,
Public Interest, Standard Contractual Clauses,
Article 44 General principle for transfers NOT APPLICABLE YES
Binding Company Rules, Regulatory Approvals, etc.)
Depending on the legal basis, check the required

evidence in Articles 45 to 49.
Transfers on the basis of an
Article 45 Control of data transfer mechanism NOT APPLICABLE YES
adequacy decision
Transfers subject to appropriate
safeguards
Control of data transfer mechanism (Binding
Article 47 Binding corporate rules NOT APPLICABLE YES
Corporate Rules (BCRs))
Transfers or disclosures not
authorised by Union law
Article 49 Derogations for specific situations Control of data transfer mechanism NOT APPLICABLE YES
Page 63 of 124
Regulation's
Article
Safeguards and derogations relating Data Protection Policy

NOT
to processing for archiving Procedure for data anonymization for processing
IMPLEMENTED
Article 89 purposes in the public interest, related to scientific research / statistical research NO
scientific or historical research Keeping documentation for deviations from the
purposes or statistical purposes NOT APPLICABLE
GDPR due to special processing cases (if required)
Existing data protection rules of
Article 91 Data Protection Policy NOT APPLICABLE YES
churches and religious associations
Page 64 of 124
From the gap analysis findings, the following set of organisational/legal requirements has been derived,
aiming to the satisfaction of all the “In progress” and “Not Implemented” cases of Table 10.
Table 11: GDPR requirements derived from GAP analysis
Organisational/Legal Requirements
Requirement ID Requirement
Conduct a Data Protection Impact Assessment regarding the

GDPR-01
processing of personal data

GDPR-02
lawfulness of processing

GDPR-03
Lawfulness of processing of special categories of personal data

GDPR-04
Responsibility of the controller
Conduct a Data Protection Impact Assessment regarding the Data

GDPR-05
protection by design and by default principle
Conduct a Data Protection Impact Assessment regarding the security

GDPR-06
of processing
Conduct a Data Protection Impact Assessment as demanded by

GDPR-07
Article 35 of the GDPR regulation
Define a Data Protection Policy for describing the process to maintain

GDPR-08
data quality
Define a Data Protection Policy for describing the process for data
GDPR-09
retention period
Define a Data Protection Policy for describing the process for

GDPR-10
acquiring data subjects' consent

GDPR-11
managing/satisfying the rights of the data subjects

GDPR-12 acquiring and using data (including special categories of personal
data)

GDPR-13
informing data subjects about the ways of processing of their data

GDPR-14 notifying the supervisory authority/data subjects about a personal
data breach
Page 65 of 124
Organisational/Legal Requirements
Define a Data Protection Policy for describing the process for internal
GDPR-15
review/auditing of policy implementation

GDPR-16 accommodating data protection by design and by default
specifications

GDPR-17 immediate notification of the controller and the data subjects (if
necessary) about a personal data breach
Define a Data Protection Policy for describing the process for Aligning
GDPR-18
Data Protection Policy with Security Policy
Define a Data Protection Policy for describing the process for data
GDPR-19 anonymization for processing related to scientific research /
statistical research
GDPR-20 Maintain records of processing activities
GDPR-21 Maintain documents as a proof of compliance
GDPR-22 Maintain documents to prove the lawfulness of processing
Maintain documents to prove the lawfulness of processing of special

GDPR-23
categories of personal data
GDPR-24 Maintain a record of incidents/breaches
Maintain the list of notifications to the supervisory authority/data

GDPR-25
GDPR-26 Maintain record/log of actions when dealing with a data breach
GDPR-27 Conduct a Risk Analysis Study
Define security measures based on the risk level (e.g.

GDPR-28 pseudonymization, encryption, access control, firewall, network
intrusion detection, logs, etc.)
4.3 STAGE 3: SECURITY AND PRIVACY REQUIREMENTS ELICITATION

4.3.1 Introduction
As described in Section 3.2.3, the Security and Privacy requirements elicitation process will be realized
through three distinct steps. During the first step the boundaries of the under study (BIONIC) system
will be defined, together with the list of system assets and stakeholders. Furthermore, the high level
security and privacy goals of the BIONIC stakeholders will be specified. During the second step a Risk
Page 66 of 124
Analysis of the system will be performed in order to initially identify potential threats and existing
vulnerabilities. While risk analysis also includes the estimation of the impact that a security incident may
cause to the stakeholders of the system, this will be performed in WP6 as it is not part of this deliverable.
Finally, during the third step, the results of the risk analysis will be employed in order to elicit the security
and privacy requirements related to the security and privacy goals addressed in step 1.
The Risk Analysis methodology that will be employed during the BIONIC project is MONARC (in French:
“Méthode Optimisée d’aNAlyse des Risques CASES”) (MONARC, 2019). MONARC simplifies risk
management by providing a solution based on industry standards, allows analysis from existing and
customizable models to be made in a short amount of time while remaining compliant with the ISO/IEC
27005:2011 standard. The MONARC risk analysis method is composed of four phases:
Phase 1: Context Establishment – The first phase is to identify the context, challenges, and priorities of
the company or organization that wishes to analyze its risks. This especially serves to identify key
activities and critical processes of the business in order to guide the risk analysis towards the most
important elements.
Phase 2: Context Modelling – The second phase includes the modelling and the definition if the
boundaries of the system to be studied. The assets that were identified in the previous step must now
be detailed and formalized in a diagram that displays their interdependencies. Impacts are defined at
the level of the primary assets (processes or information). The secondary assets inherit the impact of
the primary asset to which they are attached.
Phase 3: Evaluation and treatment of risks – The third phase included the evaluation which consists of
quantifying the threats, vulnerabilities, and impacts in order to calculate the risks. To do this, it is
necessary to have reliable information about the exact likelihood of the threats, the ease of exploitation
of vulnerabilities and potential impacts. When the risk assessment identifies a risk that is higher than
the acceptable level (risk acceptance grid), risk treatment measures should be implemented in order to
reduce the risk down to an acceptable level.
Phase 4: Implementation and monitoring – The fourth step describes the proper security processes that
should be established for safeguarding the ongoing management of the phase with security monitoring
and the security measures that must be entered in order to improve systems sustainability.
4.3.2 Step 1: Identify System Assets, Stakeholders, Security and Privacy Goals
Through Stage 1 (Section 4.1), it has been decided that the Bionic purpose of processing: PP1: Evaluate
medical data to improve employees’ health, is the only one that will be considered during the security
and privacy analysis. For this purpose of processing (PP1) and taking into account the architectural /
functional characteristics of the BIONIC system and its proposed Use Cases (Section 2, Deliverable D1.2:
“Usage scenarios for validating Bionic system in real working conditions”, Deliverable D1.3: “Medical
Requirements and Related Parameters” and Deliverable D1.5: “High-level system architecture and
technical specifications”), Figure 17 below depicts the “system” that will be studied in terms of security
and privacy, together with the involved BIONIC stakeholders.
In Section 7.2 - APPENDIX B: Data Flows Among BIONIC Components and Technologies Implementing
the Required Communication Links, Table 19, the readers may find, in tabular form, the BIONIC system’s
components acting as data sources with the respective BIONIC components acting as recipients of the
data, together with the detailed description of the data types exchanged. Furthermore, in Table 20 of
Page 67 of 124
the same Appendix, the technologies employed for the implementation of the required communication
links are described.
Figure 17. Architectural view of the BIONIC System for the Security and Privacy Analysis
The identified assets of the BIONIC system are listed in the following Table.
Table 12: Assets of the BIONIC System
Asset ID Asset Comments
AS-01 Sensors Hardware
AS-02 Smart Sensor Hub Hardware
AS-03 AI Co-Processor Hardware (AI chip)
AS-04 Smart Watch Hardware
Back End BIONIC Storage Platform

AS-05
Data Base Server Hardware

AS-06
Application Server Hardware
BIONIC EDGE device Application

AS-07 Runs on the worker’s mobile phone
Software
BIONIC Gamification Application

AS-08 Runs on the worker’s mobile phone
Software
AS-09 Transmitted Data
AS-10 Stored Data
Page 68 of 124
Asset ID Asset Comments
AS-11 Sensor's Firmware/Software
Smart Sensor's Hub

AS-12
Firmware/Software
AS-13 Smart Watch Firmware/Software
AS-14 AI Co-ProcessorFirmware/Software
The system software (operating system) of the

two servers will be considered only as a
System software for the DataBase and
AS-15 potential risk source for the BIONIC applications
Application Servers
/ data. They will not be considered as BIONIC
assets that need to be protected.
The personal access devices are PCs that

workers, ergonomists etc may use to access the
BIONIC system. The system software (operating
System software for personal access system) of personal access devices will be
AS-16
devices considered only as a potential risk source for
the BIONIC applications / data. It will not be
considered as a BIONIC asset that needs to be
protected.
The operating software of the worker’s mobile

phone (EDGE Device) will be considered only as
AS-17 EDGE Device OS a potential risk source for the BIONIC
applications / data. It will not be considered as
a BIONIC asset that needs to be protected.
Includes:
• Adminstrative Interface Software

Back End BIONIC Storage Platform • Worker Web Interface Software
AS-18
Application Server Software • Phisician Web Interface Software
• Ergonomist Web Interface Software
• Manager Web Interface Software

AS-19
Database Server Software (DBMS)
In addition to the aforementioned BIONIC assets, Table 13 below identifies the communication channels
involved in the BIONIC architecture, which are potential risks sources and thus should be also protected.
Page 69 of 124
Table 13: BIONIC Communication Channels
Link ID Communication Link Comments
CO-01 Wired Wired connection from Sensors to [Smart Sensor Hub / AI Co-
Processor] hardware box
Wired Internet connection for BIONIC user's Personal access

devices.
CO-02 USB USB connection among Smart Sensor Hub and AI Co-Processor
in the same hardware box
CO-03 Bluetooth Two way Bluetooth connection among [Smart Sensor Hub / AI
Co-Processor] hardware box and the Smart Watch
Bluetooth connection among Mobile Device and Smart Watch
CO-05 WiFi WiFi (over HTTP) connection among [Smart Sensor Hub / AI Co-
Processor] hardware box and the Mobile Device.
WiFi (over HTTP) connection among users' Personal access

devices or Mobile devive and the cloud servers
(web/application/database)
CO-06 LTE/3G LTE/3G (HTTP) connection among the Mobile device and the
cloud servers (web/application/database). This connection will
be only considered as a potential risk source for the BIONIC
applications / data
Finally, the identified user categories (types of stakeholders) of the BIONIC System are classified in the
following roles:
Table 14: BIONIC User Roles
User Type Description End User
Worker All types of workers working on the construction sites or the

ACCIONA/MTU
production line.
Ergonomist The person in charge for setting the training goals for the
workers and seeing their progress through the BIONIC ACCIONA
platform
Physiologist The doctors in charge for setting the training goals for the
workers and seeing their progress through the BIONIC MTU
platform
Manager The person in charge for receiving anonymised reports

through the BIONIC platform for improving working ACCIONA/MTU
conditions with the top management
Administrator Technical personnel ACCIONA/MTU
Page 70 of 124
Based on the functional requirements derived for the BIONIC system, the goals and functionalities that
the system should fulfil, the stakeholder’s needs, as mainly expressed through the two end users of the
consortium (ACCIONA and MTU) and the data presented in Section 7.2 - APPENDIX B: Data Flows
Among BIONIC Components and Technologies Implementing the Required Communication Links as
agreed among all partners, the security and privacy goals that the BIONIC system should meet are the
following:
Table 15: BIONIC Security and Privacy Goals
Goal ID Category Description
G-01 Integrity Ensure the integrity of stored and transmitted data
G-02 Availability Ensure the availability of the BIONIC services to all eligible users
G-03 Confidentiality Ensure the confidentiality of stored and transmitted data
G-04 Anonymity Ensure worker’s anonymity
The worker’s edge device and the BIONIC storage should be

G-05 Unlinkability
unlinkable
4.3.3 Step 2: Security and Privacy Threats and related System Vulnerabilities
For identifying the Threats/Attacks against the BIONIC assets the following sources have been
employed:
• Input from ENISA (ENISA, Dec. 2018), (ENISA, Apr. 2018) about IoT and relevant
recommendations.
• Threats suggested by the MONARC methodology (MONARC, 2019).
• Threats identified by BIONIC partners and end users
• Past experience of the researchers involved in the BIONIC project
The final list of Threats that has been compiled is depicted in Table 16. The BIONIC assets that could be
affected by each individual threat together with the security and privacy goals described in the table
before are also presented in the same Table.
Having identified the BIONIC assets and the threats against these assets, the MONARC methodology has
been utilized in order to identify the system vulnerabilities that can be exploited by each threat in order
to harm the system. Table 17 lists all these vulnerabilities per identified Threat.
Page 71 of 124
Table 16: Threats against BIONIC assets

Threat /
Threat ID Description Availability Confidentiality Integrity Unlinkability Anonymity Affected Assets
Attack
Multiple systems attack a single target to overfill it and

make it fail. This can be done by making many
connections, flooding a communication channel or
replaying the same communications again and again.
Moreover, a Denial of Service can target an IoT system
Denial of Application Server Software, AI Co-
TH-IOT-01 resulting in system unavailability and production X
Service ProcessorFirmware/Software, WiFI and
disruption caused by a massive number of requests sent
Bluetooth communication Links
to the system. Or, an attacker may take advantage of IIoT
devices in an industrial environment and create a network
of infected IoT botnets as a platform to attack some other
system.

Application Server Software, Back End
The software may carry out unwanted and unauthorized
BIONIC Storage Platform Database Server
actions on a system without the consent of the user,
Software (DBMS), Smart Sensor's Hub
resulting in damage, corruption or information theft. The
Firmware/Software, Smart Watch
TH-IOT-02 Malware penetration of malicious software in an IIoT aimed at X X X X
Firmware/Software, AI Co-
performing undesired and unauthorized actions, which
ProcessorFirmware/Software, BIONIC
may produce damage to a system, operational processes,
EDGE device Application Software, BIONIC
and related data.
Gamification Application Software, Stored
Data

Unauthorized manipulation of devices software or
Application Server Software, Sensor's
applications within an IoT system by an attacker. In terms
Firmware/Software, Smart Watch
Manipulation of industrial IoT systems, an attacker’s actions may
TH-IOT-03 X X X X Firmware/Software, AI Co-
of software include manipulation of embedded systems software
ProcessorFirmware/Software, BIONIC
mobile devices or modification of its software
EDGE device Application Software, BIONIC
configuration.
Gamification Application Software
Page 72 of 124
Threat /
Attack
Unauthorized manipulation of devices hardware or Sensors Hardware, Smart Sensor Hub

Modification hardware tampering of IoT system by an attacker. In Hardware, AI Co-Processor Hardware (AI
TH-IOT-04 X X
of Hardware terms of industrial IoT systems, an attacker’s actions may chip), Smart Watch Hardware, Wired and
include manipulation of embedded systems hardware. USB communication Links
Unwanted and unauthorized data access or / and

Manipulation modification by an attacker may apply to compromise
Stored Data, Transmitted Data (through
TH-IOT-05 of operational or manipulation of process data. Possible X X X X
WiFi or Bluetooth)
Information consequences may include inappropriate decisions based
on falsified data.
The threat of a cyberattack aims at harming an

organization possibly to take control over the system
using various technical means such as compromising key
devices and falsifying telemetry deceiving unaware
Targeted operators. Other impacts include damage to reputation or Back End BIONIC Storage Platform
TH-IOT-06 X X X
cyber attacks theft of company secrets. This attack is different from Application Server Software
wider scale attacks whose objective is to infect any
company that connects to a certain website prepared by
an attacker or any company that uses a device or software
with a certain vulnerability.
The threat of discoloring personal/sensitive information

stored on devices or in the cloud. The attacker’s goal is to
Abuse of gain unauthorized access to this kind of data and use it
TH-IOT-07 X X X X Stored Data
personal data illicitly. Production data is not considered to be subject to
privacy but it may also pose problems if it can be linked to
the performance of individual employees.
Page 73 of 124
Threat /
Attack
Stored Data, Transmitted Data (possible

Counterfeit This threat refers to a counterfeit device that usually has
sources in this case are considered only the
TH-IOT-08 by malicious backdoors and can be used to conduct attacks on other X X
Sensors Hardware and the Smartwatch
devices IoT devices in the environment.
hardware)
The threat of gaining unauthorized access to BIONIC's

infrastructure resources (i.e. data, systems, devices, etc.) Back End BIONIC Storage Platform
TH-IOT-09 Brute force X X
through a large number of attempts to guess the correct Application Server Software
key or password.
The threat of active eavesdropping, where messages

exchanged between unaware affected parties are relayed
Man-in-the- Stored Data, Transmitted Data (through
TH-IOT-10 by an attacker. The attacker may just listen to the X X X X X
Middle WiFi or Bluetooth)
exchanged messages or modify or delete transmitted
information, leading to communication disruption.
Session Stealing the data connection by acting as a legitimate user

TH-IOT-11 X X X Stored Data
hijacking in order to steal, modify or delete transmitted data.
Interruption or failure in the network supply, either

Network
TH-IOT-12 intentional or accidental. Depending on the network X WiFi
Outage
segment affected, and on the time required to recover.
Sensors Hardware, Smart Sensor Hub

Hardware, AI Co-Processor Hardware (AI
chip), Smart Watch Hardware, Back End
Failures of
TH-IOT-13 The threat of failure or malfunction of devices. X BIONIC Storage Platform Data Base Server
devices
Hardware, Back End BIONIC Storage
Platform Application Server Hardware,
Wired and USB communication Links
Page 74 of 124
Threat /
Attack

Failure of Firmware/Software, Smart Watch
TH-IOT-14 Threat of failure of software services or applications X
system Firmware/Software, AI Co-Processor
Firmware/Software, Sensor's
Firmware/Software, BIONIC EDGE device
Application Software, BIONIC Gamification
Application Software

IoT devices are often vulnerable due to weak/default
Software passwords, software bugs, and configuration errors,
TH-IOT-15 X X X X Firmware/Software, Smart Watch
vulnerabilities posing a risk to the network. This threat is usually
Firmware/Software, AI Co-Processor
connected to others, like exploit kits.
Firmware/Software, BIONIC EDGE device
Application Software, BIONIC Gamification
Application Software
Sensors Hardware, Smart Sensor Hub

These include events such as, floods, heavy winds, heavy Hardware, AI Co-Processor Hardware (AI
Natural snows, landslides, among other natural disasters or and chip), Smart Watch Hardware, Back End
TH-IOT-16 X
Disaster other disasters in the deployment environment, that can BIONIC Storage Platform Data Base Server
damage the devices or cause their inoperability Hardware, Back End BIONIC Storage
Platform Application Server Hardware
Device Incidents such devices theft, bomb attacks, vandalism or Sensors Hardware, Smart Sensor Hub
TH-IOT-17 X
destruction sabotage could damage devices Hardware, AI Co-Processor Hardware (AI
Page 75 of 124
Threat /
Attack
chip), Smart Watch Hardware, Wired and

USB communication Links
Page 76 of 124
Table 17: Vulnerabilities that can be exploited by each identified Threat

Vulnerability ID Vulnerability Threat ID Threat / Attack
VU-CO-01 Access point allowing unlawful eavesdropping TH-IOT-10 Man-in-the-Middle
TH-IOT-07 Abuse of personal data
VU-CO-02 Additional hardware items can be fitted for storing, transmitting or corrupting information (e.g. physical
TH-IOT-04 Modification of Hardware
keylogger).
VU-CO-03 Additional software can be added for storing, transmitting or corrupting information (e.g. keylogger) TH-IOT-02 Malware
VU-CO-04 Ageing of the equipment TH-IOT-13 Failures of devices
VU-CO-05 Ageing of the medium TH-IOT-13 Failures of devices
VU-CO-06 Communication in broadcast mode TH-IOT-10 Man-in-the-Middle
VU-CO-07 Equipment accessible to unauthorised persons TH-IOT-04 Modification of Hardware
VU-CO-08 Equipment sensitive to electrical disturbances (voltage drops, overvoltages, transient power-cuts) TH-IOT-13 Failures of devices
VU-CO-09 Equipment that is complex to use or not user-friendly TH-IOT-14 Failure of system
VU-CO-10 Fragility of equipment TH-IOT-13 Failures of devices
VU-CO-11 Incorrect operating conditions TH-IOT-13 Failures of devices
VU-CO-12 Incorrect sizing (e.g. too much data for the maximum passband) TH-IOT-01 Denial of Service
VU-CO-13 Interface side effects (compatibility problems between protocols, etc.) TH-IOT-14 Failure of system
VU-CO-14 Interface with a function that allows eavesdropping TH-IOT-10 Man-in-the-Middle
VU-CO-15 Maintenance fault TH-IOT-13 Failures of devices
Page 77 of 124
VU-CO-16 Media accessible to unauthorised persons TH-IOT-13 Failures of devices
VU-CO-17 Medium and supports whose characteristics allow eavesdropping (e.g. Ethernet, wireless communication TH-IOT-10 Man-in-the-Middle
systems)
VU-CO-18 No accessible user support TH-IOT-14 Failure of system
VU-CO-19 No authentication of equipment connected to the network TH-IOT-10 Man-in-the-Middle
VU-CO-20 No physical protection TH-IOT-10 Man-in-the-Middle
VU-CO-21 No robust access control system TH-IOT-10 Man-in-the-Middle
VU-CO-22 Obsolete hardware TH-IOT-13 Failures of devices
VU-CO-23 Physical access to communication support or equipment allowing eavesdropping equipment to be installed TH-IOT-10 Man-in-the-Middle
VU-CO-24 Physical or logical access to a relay allowing eavesdropping equipment to be installed TH-IOT-10 Man-in-the-Middle
VU-CO-25 Poor equipment reliability TH-IOT-13 Failures of devices
VU-CO-26 Poor management of pilot releases and configurations TH-IOT-14 Failure of system
VU-CO-27 Poor medium reliability TH-IOT-13 Failures of devices
VU-CO-28 Possibility of adding software derivations TH-IOT-02 Malware
Page 78 of 124
TH-IOT-15 Software vulnerabilities
VU-CO-29 Possibility of circuit derivation TH-IOT-04 Modification of Hardware
VU-CO-30 Possibility of corrupting a communication TH-IOT-10 Man-in-the-Middle
VU-CO-31 Possibility of incorrect configuration, installation or modification of relays TH-IOT-14 Failure of System
VU-CO-32 Possibility of interfering with data transmitted via the communication media TH-IOT-10 Man-in-the-Middle
VU-CO-33 Possibility of remote administration of the system using non-encrypted administration tools TH-IOT-11 Session hijacking
VU-CO-34 Possibility of remote system administration TH-IOT-11 Session hijacking
VU-CO-35 Possibility of remote system administration from any station TH-IOT-02 Malware
VU-CO-36 Possibility of subjecting the relays to an excessive number of requests or intense interference (e.g. denial of
TH-IOT-01 Denial of Service
service attacks such as smurfing, SYN flood etc.)
VU-CO-37 Presence of a communication network with the outside allowing exchange of information TH-IOT-10 Man-in-the-Middle
TH-IOT-06 Targeted cyber attacks
Page 79 of 124
VU-CO-38 Presence of protocol that has no authentication function TH-IOT-10 Man-in-the-Middle
VU-CO-39 Protocol not allowing safe authentication of the sender of a communication TH-IOT-11 Session hijacking
VU-CO-40 Standard interface allowing information exchanges (e.g. Bluetooth interface accepting all communications by TH-IOT-10 Man-in-the-Middle
default)
VU-CO-41 The equipment can be accessed by everyone TH-IOT-17 Device destruction
TH-IOT-04 Modification of Hardware
Counterfeit by malicious
TH-IOT-08
devices
VU-CO-42 The interfaces can be accessed by everyone TH-IOT-07 Abuse of personal data
VU-CO-43 The network makes it easy for unauthorised persons to use the resources TH-IOT-07 Abuse of personal data
TH-IOT-06 Targeted cyber attacks
TH-IOT-02 Malware
Manipulation of
TH-IOT-05
Information
Page 80 of 124
VU-CO-44 The relays identify neither the sources nor the destinations (example of impact: system vulnerable to spoofing
TH-IOT-10 Man-in-the-Middle
attacks)
VU-CO-45 The supports and medium can be accessed by everyone and are active by default (e.g. RJ45 connectors TH-IOT-02 Malware
intermingled)
Manipulation of
TH-IOT-05
Information
VU-CO-46 Unidentified underground equipment Manipulation of

TH-IOT-05
Information
Counterfeit by malicious
TH-IOT-08
devices
VU-CO-47 Users lack competency TH-IOT-14 Failure of system
VU-SO-01 Software that is complex to use TH-IOT-14 Failure of system
VU-SO-02 Possibility of the operating system being subjected to badly formed requests and data (e.g. buffer overflow) TH-IOT-02 Malware
TH-IOT-03 Manipulation of software
VU-SO-03 Use of an obsolete version of the operating system or applications TH-IOT-02 Malware
VU-SO-04 Single internally-developed applications TH-IOT-16 Natural Disaster
VU-SO-05 Lack of responsibility TH-IOT-14 Failure of system
VU-SO-06 No encryption system TH-IOT-07 Abuse of personal data
Page 81 of 124
VU-SO-07 Software can be used by everyone (e.g. no password required for remote administration of a workstation) TH-IOT-07 Abuse of personal data
VU-SO-08 No restriction on software entry points TH-IOT-07 Abuse of personal data
VU-SO-09 No implementation of basic security rules applicable to the operating system and software TH-IOT-02 Malware
VU-SO-10 Use of non-evaluated software TH-IOT-15 Software vulnerabilities
VU-SO-11 No protection against the use of advanced privileges TH-IOT-02 Malware
VU-SO-12 Possibility of modifying or corrupting the software TH-IOT-02 Malware
VU-SO-13 No sure means of identification TH-IOT-07 Abuse of personal data
VU-SO-14 No procedure or system for authorising personnel to modify data TH-IOT-07 Abuse of personal data
Page 82 of 124
VU-SO-15 No monitoring of data integrity TH-IOT-07 Abuse of personal data
VU-SO-16 No management of profile privileges (administrators, users, guest, etc.) TH-IOT-07 Abuse of personal data
VU-SO-17 Possibility of installing a backdoor or Trojan horse in the operating system TH-IOT-02 Malware
VU-SO-18 Non-upgradable software TH-IOT-02 Malware
VU-SO-19 Obsolete software TH-IOT-02 Malware
VU-SO-20 Applications are not checked before installation TH-IOT-02 Malware
VU-SO-21 Possibility of incorrect configuration, installation or modification of the operating system TH-IOT-14 Failure of system
VU-SO-22 No systematic qualification procedure before installation or updating TH-IOT-14 Failure of system
VU-SO-23 Lack of training in maintaining and operating new equipment TH-IOT-14 Failure of system
VU-SO-24 Possible side effects after updating a software component TH-IOT-14 Failure of system
Page 83 of 124
VU-SO-25 Application requiring computing resources not matched by the equipment (e.g. insufficient RAM) TH-IOT-14 Failure of system
VU-SO-26 No filter to protect the system against saturation TH-IOT-12 Network Outage
TH-IOT-14 Failure of system
VU-SO-27 Possible existence of hidden functions introduced during the design and development phase TH-IOT-02 Malware
VU-SO-28 Software retrieval from a non-authenticated source TH-IOT-02 Malware
VU-SO-29 Presence of residual data used by the software TH-IOT-07 Abuse of personal data
VU-SO-30 Possibility of adding an eavesdropping programme such as a Trojan horse TH-IOT-02 Malware
VU-SO-31 Password for accessing the system or application changed rarely or not at all TH-IOT-09 Brute force
VU-SO-32 Use of easily-observed passwords to access the system or application (shape on keyboard, short password) TH-IOT-07 Abuse of personal data
VU-OS-01 The operating system allows a session to be opened without password TH-IOT-11 Session hijacking
Page 84 of 124
VU-OS-02 No accessible support TH-IOT-13 Failures of devices
VU-OS-03 Insufficient competency TH-IOT-13 Failures of devices
VU-OS-04 The operating system is not checked before installation TH-IOT-13 Failures of devices
VU-OS-05 Resource sharing makes it easy for unauthorised persons to use the system TH-IOT-07 Abuse of personal data
Manipulation of
TH-IOT-05
Information
VU-OS-06 Use of a standard operating system on which logical attacks have already been carried out TH-IOT-02 Malware
VU-OS-07 Connection passwords not sufficiently complex TH-IOT-09 Brute force
VU-OS-08 Possibility of creating or modifying system commands TH-IOT-02 Malware
Page 85 of 124
4.3.4 Step 3: Security and Privacy Requirements

The scope of this step is to identify, for the BIONIC purpose of processing: PP1: Evaluate medical data
to improve employees’ health, the set of the security and privacy requirements that should be satisfied.
To identify the appropriate requirements the following process was followed: Following the security and
privacy goals mentioned in Table 15 we identified the respective Threats and Vulnerabilities. For each
Threat-Vulnerability pair (meaning that the specific threat can exploit the specific vulnerability - see
Table 17) the affected BIONIC assets were examined (see Table 16), thus guiding us to the specification
of the security and privacy properties that should be protected and thus to the elicitation of the
appropriate requirements. The aforementioned elicitation process ensures the mitigation of the
identified threats and thus the achievement of the appropriate protection level for the BIONIC system.
Table 18 lists the derived security and privacy requirements for the BIONIC system. For the full analysis
of how each requirement has been derived the reader may refer to section 7.2 - APPENDIX C: Elicitation
of Security and Privacy Requirements for the BIONIC System.
Table 18: Security and Privacy Requirements for the BIONIC System
Security and Privacy Requirements
SP-RE-01 Ensure Data confidentiality during transmission
SP-RE-02 Ensure Data integrity during Transmission

SP-RE-03 Ensure availability of the communication channel
Ensure that only legitimate devices interact with the BIONIC system (ensure the
SP-RE-04
validity of hardware devices)
SP-RE-05 Ensure the origin and integrity of BIONIC firmware/software
SP-RE-06 Ensure secure deployment of BIONIC firmware/software
SP-RE-07 Ensure the quality of the hardware devices
SP-RE-08 Ensure the quality and the timeliness of the hardware maintenance services
SP-RE-09 Ensure that crucial hardware devices are tamper proof
SP-RE-10 Ensure the quality and the timeliness of the software maintenance services
SP-RE-11 Ensure appropriate training / awareness programs for the BIONIC users
Ensure availability of required hardware resources (processing power, storage space,
SP-RE-12
memory space)
SP-RE-13 Ensure interoperability of BIONIC software components
SP-RE-14 Ensure the authenticity of the hardware components connected to the BIONIC system
SP-RE-15 Ensure that only authorised users can access the BIONIC system
Ensure the reliability and security of the BIONIC software development process
SP-RE-16
(Security and Privacy by Design)
SP-RE-17 Ensure that abnormal network activity (requests, traffic) can be detected
SP-RE-18 Ensure that there is physical access control to crucial BIONIC equipment
Page 86 of 124
Security and Privacy Requirements
Ensure recovery of crucial BIONIC assets after natural disasters and other physical
SP-RE-19
threats
SP-RE-20 Ensure Data confidentiality of stored data
SP-RE-21 Ensure Data integrity of stored data
SP-RE-22 Ensure that authorized users have the correct privileges
SP-RE-23 Ensure worker’s anonymity

SP-RE-24 Unlinkability between BIONIC EDGE device and the BIONIC storage platform
The specific list of twenty four (24) requirements, presented in Table 18, along with the list of twenty
eight (28) organisational/legal requirements identified and presented in Table 11, form the complete
list of fifty two (52) requirements derived through the application of the Privacy and Data Protection
Framework. The satisfaction of the aforementioned requirements will ensure that the BIONIC system
will comply with GDPR, will protect the privacy of the workers and will exhibit all the appropriate
countermeasures against potential security threats.
Page 87 of 124
4.4 STAGE 4: IMPACT ESTIMATION FROM SECURITY/PRIVACY VIOLATION INCIDENTS
Stage 4 will be implemented in Work package 6, task 6.6, deliverable 6.4 “Data protection (Security and
Privacy) Measures”. In this stage the following tasks will be performed in order to identify the correct
technical security and privacy measures for the proposed requirements presented in Table 11 and in
Table 18:
• Proceed with the application of a Data Protection Impact Assessment methodology in order to
identify potential new risks related to the identified requirements and assure than non-
conflicting requirements indeed serve the project’s goals. The DPIA methodology that will be
employed is the one proposed by the French Data Protection Authority (CNIL).
• Continue with the estimation of the impact (consequences) that a potential security or privacy
violation incident may cause to the BIONIC stakeholders and data subjects through the
MONARC risk analysis methodology.
• Continue with the application of the PriS methodology in order to model the final set of security
and privacy requirements with the rest of BIONIC organizational goals and identify the
security/privacy related processes for the system.
• Identify and propose the list of technical security and privacy measures for satisfying the
identified security and privacy needs in the BIONIC context.
Page 88 of 124
5 CONCLUSION AND NEXT STEPS

The main purpose of this deliverable was to propose a Privacy and Data Protection Framework that will
be applied at the early stages of the BIONIC system design for guaranteeing that the development of
the applications / architecture will follow a privacy-by-design approach and also for ensuring the
satisfaction of all functional and non-functional (security and privacy) requirements imposed by the
users.
Having described the BIONIC use case scenarios in chapter 2, in chapter 3 a four stages framework has
been presented for the identification of both the legal/organisational requirements derived from the
General Data Protection Regulation (GDPR) but also the technical security and privacy requirements for
the BIONIC system.
Based on the BIONIC proposal during the design phase all, legal and technical, requirements of the
General Data Protection Regulation (GDPR) should be considered. Indicatively, it will be ensured that
principles like the data protection (purpose limitation, data minimization, accuracy, accountability), the
lawfulness of processing, the user consent, are fully satisfied. The applications will respect all the rights
of the data owners (workers) like their right to object to the storage/processing of their information,
their right to be forgotten, their right to restriction of processing etc. Finally, all necessary technical,
organizational and procedural measures will be considered to address the GDPR requirements related
to data protection, accountability and handling of potential data breaches. Beside the description of the
proposed privacy and data protection framework the scope of this deliverable was to identify and
present the initial high-level security and privacy requirements elicitation by analysing both the GDPR
related processes as well as the technical security and privacy requirements derived from the functional
requirements of the BIONIC system.
In chapter 4 the proposed privacy and data protection framework has been applied to the BIONIC
system. Specifically, the framework was applied in order to identify the purposes of processing for the
BIONIC project and, then, for every purpose to analyze the GDPR compliance level as well as the current
security and privacy threats/vulnerabilities. For the BIONIC project two purposes of processing were
identified while only the first one was considered for further analysis since the second one does not
handle any type of personal data. For the unique purpose of processing a gap analysis was conducted
in order to conclude with the elicitation of the first set of organizational/legal requirements based on
the GDPR requirements for the BIONIC project. The outcome was a set of twenty-eight (28)
requirements. Then a risk analysis was conducted for the elicitation of the technical security and privacy
requirements. MONARC was used as a tool for the whole risk analysis and the input for the risk analysis
was taken by ENISA, input from BIONIC partners and end users, input from MONARC as well as past
experience from the researchers of the consortium. From the risk analysis a new set of twenty-four (24)
requirements was derived. In total 52 new requirements were proposed and will be further analyzed in
Deliverable 6.4 “Data protection (Security and Privacy) Measures” in WP6.
Page 89 of 124
6 REFERENCES
Alagar, V., Periyasamy K., and Wan, K. (2017). "Privacy and security for patient-centric elderly health
care," 2017 IEEE 19th International Conference on e-Health Networking, Applications and Services
(Healthcom), Dalian, 2017, pp. 1-6
Alibasa, M. J., Santos, M. R., Glozier, N., Harvey, S. B. and Calvo, R. A. (2017) "Designing a secure
architecture for m-health applications," 2017 IEEE Life Sciences Conference (LSC), Sydney, NSW,
2017, pp. 91-94.
Al-Janabi, S., Al-Shourbaji, I., Shojafar, M., & Shamshirband, S. (2017). Survey of main challenges
(security and privacy) in wireless body area networks for healthcare applications. Egyptian
Informatics Journal, 18(2), 113-122.
Almarashdeh, I., Alsmadi, M., Hanafy, T., Albahussain, A., Altuwaijri, N., Almaimoni, H.,& Al Fraihet,
A. (2018). Real-time elderly healthcare monitoring expert system using wireless sensor
network. International Journal of Applied Engineering Research ISSN, 0973-4562.
Antignac, T., Scandariato, R., & Schneider, G. (2018, April). Privacy compliance via model
transformations. In 2018 IEEE European Symposium on Security and Privacy Workshops
(EuroS&PW) (pp. 120-126). IEEE.
Bhuiyan, M. Z. A., Zaman, M., Wang, G., Wang, T., & Wu, J. (2017, August). Privacy-protected data
collection in wireless medical sensor networks. In 2017 International Conference on Networking,
Architecture, and Storage (NAS) (pp. 1-2). IEEE.
Carbonaro, G., Leanza, E., McCann, P., & Medda, F. (2018). Demographic decline, population aging,
and modern financial approaches to urban policy. International Regional Science Review, 41(2), 210-
232.
Cavoukian, A. (2012). Privacy by design [leading edge]. IEEE Technology and Society
Magazine, 31(4), 18-19.
Chib, A., & Lin, S. H. (2018). Theoretical Advancements in mHealth: A Systematic Review of Mobile
Apps. Journal of health communication, 23(10-11), 909-955.
De Hert, P., Papakonstantinou, V., Malgieri, G., Beslay, L., & Sanchez, I. (2018). The right to data
portability in the GDPR: Towards user-centric interoperability of digital services. Computer Law &
Security Review, 34(2), 193-203.
Drosatos, G., Efraimidis, P. S., Williams, G., & Kaldoudi, E. (2016, February). Towards Privacy by
Design in Personal e-Health Systems. In HEALTHINF (pp. 472-477).
Dumas, J. (2018). General Data Protection Regulation (GDPR): Prioritizing Resources. Seattle UL
Rev., 42, 1115.
Edemacu, K., Park, H. K., Jang, B., & Kim, J. W. (2019). Privacy Provision in Collaborative Ehealth With
Attribute-Based Encryption: Survey, Challenges and Future Directions. IEEE Access, 7, 89614-89636.
ENISA (Dec. 2018). Good Practices for Security of Internet of Things in the Context of Smart
Manufacturing. ENISA, 18 Dec. 2018, https://www.enisa.europa.eu/publications/good-practices-
for-security-of-iot.
Page 90 of 124
ENISA (Apr. 2018). Baseline Security Recommendations for IoT. ENISA, 20 Apr. 2018,
https://www.enisa.europa.eu/publications/baseline-security-recommendations-for-iot.
Esposito, C., Castiglione, A., Tudorica, C. A., & Pop, F. (2017). Security and privacy for cloud based
data management in the health network service chain: a microservice approach. IEEE
Communications Magazine, 55(9), 102-108.
European Commission, Public health, “E-Health Policy”, 2015. [Online]. Available:

http://ec.europa.eu/health/ehealth/policy/index_en.htm.
Huth, D. (2018). A Pattern Catalog for GDPR Compliant Data Protection. In PoEM Doctoral
Consortium (pp. 34-40).
Iwaya, L. H., Fischer-Hübner, S., Åhlfeldt, R. M., & Martucci, L. A. (2018, June). mhealth: A privacy
threat analysis for public health surveillance systems. In 2018 IEEE 31st International Symposium on
Computer-Based Medical Systems (CBMS) (pp. 42-47). IEEE.
Kalloniatis, C. (2015). “Designing Privacy-Aware Systems in the Cloud”, Proceedings of the

TRUSTBUS 2015 12th International Conference on Trust Privacy and Security in Digital Business, S.
Hubner, C. Lambrinoudakis (eds), September 2015, Valencia, Spain, Springer LNCS Lecture Notes in
Computer Science.
Kalloniatis, C. (2017) “Incorporating Privacy in the Design of Cloud-Based Systems: A Conceptual

Metamodel”, Information and Computer Security Journal, Emerald https://doi.org/10.1108/ICS-06-
2016-0044
Kalloniatis, C., Kavakli, E., Gritzalis, S. (2008). Addressing privacy requirements in system design : the
PriS method. Requirements Engineering 13.3, 241-255
Kurtz, C., Semmann, M. and Böhmann, T. (2018). "Privacy by Design to Comply with GDPR: A Review
on Third-Party Data Processors" presented at the Americas Conference on Information Systems
(AMCIS), New Orleans, 2018
Lambrinoudakis, C. (2018, September). The General Data Protection Regulation (GDPR) Era: Ten
Steps for Compliance of Data Processors and Data Controllers. In International Conference on Trust
and Privacy in Digital Business (pp. 3-8). Springer, Cham.
Lee, N., & Kwon, O. (2015). A privacy-aware feature selection method for solving the
personalization–privacy paradox in mobile wellness healthcare services. Expert systems with
applications, 42(5), 2764-2771.
Li, X. (2018). Understanding eHealth literacy from a privacy perspective: eHealth literacy and digital
privacy skills in American disadvantaged communities. American Behavioral Scientist, 62(10), 1431-
1449.
Liu, L.S., Shih, P.C. and Hayes, G.R. (2011), “Barriers to the adoption and use of personal health
record systems”, Proceedings of the 2011 iConference, Seattle, WA, 8-11 February, ACM, pp. 363-
370.
Luo, E., Bhuiyan, M. Z. A., Wang, G., Rahman, M. A., Wu, J., & Atiquzzaman, M. (2018).
Privacyprotector: Privacy-protected patient data collection in IoT-based healthcare systems. IEEE
Communications Magazine, 56(2), 163-168.
Page 91 of 124
Marcolino, M. S., Oliveira, J. A. Q., D'Agostino, M., Ribeiro, A. L., Alkmim, M. B. M., & Novillo Ortiz,
D. (2018). The impact of mHealth interventions: systematic review of systematic reviews. JMIR
mHealth and uHealth, 6(1), e23.
Martin, Y. S., & Kung, A. (2018, April). Methods and tools for GDPR compliance through privacy and
data protection engineering. In 2018 IEEE European Symposium on Security and Privacy Workshops
(EuroS&PW) (pp. 108-111). IEEE.
Milutinovic, M., & De Decker, B. (2016). Ethical aspects in eHealth–design of a privacy friendly
system. Journal of Information, Communication and Ethics in Society, 14(1), 49-69.
MONARC (2019). Comparison between MONARC and Different Risk Management Methods.
MONARC, 14 Dec. 2019, https://www.monarc.lu/publications/comparison-between-monarc-and-
different-risk-management-methods/.
Mouratidis, H., Islam S., Kalloniatis C., Gritzalis S. (2013). “A framework to support selection of cloud
providers based on security and privacy requirements” in Journal of Systems and Software Vol. 86,
no 9, pp.2276-2293
Mustafa, U., Pflugel, E., & Philip, N. (2019, January). A Novel Privacy Framework for Secure M-Health
Applications: The Case of the GDPR. In 2019 IEEE 12th International Conference on Global Security,
Safety and Sustainability (ICGS3) (pp. 1-9). IEEE.
Notario, N., Crespo, A., Martin, Y.S., Del Alamo, J.M., Metayer, D.L., Antignac, T., Kung, A., Kroener,
I.,Wright, D. (2015). PRIPARE: Integrating privacy best practices into a privacy engineering
methodology. Proceedings - 2015 IEEE Security and Privacy Workshops, SPW 2015 pp. 151-158
OECD (2011). THE OECD Privacy Framework, available at:

http://www.oecd.org/sti/ieconomy/oecd_privacy_framework.pdf
Omoogun, M., Seeam, P., Ramsurrun, V., Bellekens, X., & Seeam, A. (2017, June). When eHealth
meets the internet of things: Pervasive security and privacy challenges. In 2017 International
Conference on Cyber Security And Protection Of Digital Services (Cyber Security) (pp. 1-7). IEEE.
Palmirani, M., Martoni, M., Rossi, A., Bartolini, C., & Robaldo, L. (2018, December). Legal Ontology
for Modelling GDPR Concepts and Norms. In JURIX (pp. 91-100).
Petrakaki, D., Hilberg, E., & Waring, J. (2018). Between empowerment and self-discipline: Governing
patients' conduct through technological self-care. Social Science & Medicine, 213, 146-153.
Pirbhulal, S., Samuel, O. W., Wu, W., Sangaiah, A. K., & Li, G. (2019). A joint resource-aware and
medical data security framework for wearable healthcare systems. Future Generation Computer
Systems, 95, 382-391.
PwC, (2014). The Wearable Future, Consumer Intelligence Series, Available at:
http://www.pwc.com/es_MX/mx/industrias/archivo/2014-11-pwc-the-wearable-future.pdf
Robol, M., Salnitri, M., & Giorgini, P. (2017, November). Toward GDPR-compliant socio-technical
systems: modeling language and reasoning framework. In IFIP Working Conference on The Practice
of Enterprise Modeling (pp. 236-250). Springer, Cham.
Romanou, A. (2018). The necessity of the implementation of Privacy by Design in sectors where data
protection concerns arise. Computer law & security review, 34(1), 99-110.
Page 92 of 124
Rösch, D., Schuster, T., Waidelich, L., & Alpers, S. (2019). Privacy Control Patterns for Compliant
Application of GDPR. AMCIS 2019 Proceedings > Information Security and Privacy (SIGSEC) > 27
Rubinstein, I.S. & Good, N. (2013). Privacy by Design: A Counterfactual Analysis of Google and
Facebook Privacy Incidents. Berkeley Technology Law Journal 28(2), 1333-1413.
Sawand, M. A., & Khan, N. A. (2017). Privacy and Security Mechanisms for eHealth Monitoring
Systems. INTERNATIONAL JOURNAL OF ADVANCED COMPUTER SCIENCE AND APPLICATIONS, 8(4),
533-537.
Sharma, R. (2016). “The Demographics of Stagnation: Why People Matter for Economic Growth.”
Foreign Affairs 95 (2): 18–24.
Sirur, S., Nurse, J. R., & Webb, H. (2018, October). Are We There Yet?: Understanding the Challenges
Faced in Complying with the General Data Protection Regulation (GDPR). In Proceedings of the 2nd
International Workshop on Multimedia Privacy and Security (pp. 88-95). ACM.
Smart, N., Rijmen, V., Stam, M., Warinschi, B., Watson, G., (2014). Study on cryptographic protocols.
European Network and Information Security Agency (ENISA), Report TP-06-14 085-EN-N, 11.
Soceanu, A., Vasylenko, M., Egner, A., & Muntean, T. (2015, May). Managing the privacy and security
of ehealth data. In 2015 20th International Conference on Control Systems and Computer
Science (pp. 439-446). IEEE.
Solomon, M., & Elias, E. P. (2018). Privacy Protection for Wireless Medical Sensor Data. International
Journal of Scientific Research in Science and Technology, 4(2), 1439-1440.
Sousa, M., Ferreira, D. N. G., Pereira, C. S., Bacelar, G., Frade, S., Pestana, O., & Correia, R. C. (2018).
OpenEHR Based Systems and the General Data Protection Regulation (GDPR). Building Continents
of Knowledge in Oceans of Data: The Future of Co-Created EHealth.
Tikkinen-Piri, C., Rohunen, A., & Markkula, J. (2018). EU General Data Protection Regulation:
Changes and implications for personal data collecting companies. Computer Law & Security Review,
34(1), 134-153.
Volk, M., Sterle, J. and Sedlar, U. (2015). Safety and Privacy Considerations for Mobile Application
Design in Digital Healthcare. International Journal of Distributed Sensor Networks, 2015, pp.1-12
Wagner, I., He, Y., Rosenberg, D., & Janicke, H. (2016, January). User interface design for privacy
awareness in ehealth technologies. In 2016 13th IEEE Annual Consumer Communications &
Networking Conference (CCNC) (pp. 38-43). IEEE.
WHO, (2011). “mHealth: New horizons for health through mobile technologies: second global
survey on eHealth”, ISBN 978-92-4-156425-0.
WHO, (2015) “E-Health”, 2015. [Online]. Available:

http://www.who.int/trade/glossary/story021/en/.
Zhang, X., Liu, S., Chen, X., Wang, L., Gao, B., & Zhu, Q. (2018). Health information privacy concerns,
antecedents, and information disclosure intention in online health communities. Information &
Management, 55(4), 482-493.
Page 93 of 124
Zhou, J., Lin, X., Dong, X. and Cao, Z. (2015). "PSMPA: Patient Selfcontrollable and MultiLevel Privacy-
Preserving Cooperative Authentication in Distributed-Healthcare Cloud Computing System," in IEEE
Transactions on Parallel and Distributed Systems, vol. 26, no. 6, pp. 1693 1703, 1 June 2015.
Page 94 of 124
7 APPENDICES
7.1 APPENDIX A: QUESTIONNAIRE FOR STAGE 1

The questionnaire used for the elicitation of the necessary information from the two end users
regarding Stage 1 is given below.
Page 95 of 124
Page 96 of 124
Figure 18. Questionnaire for Supporting Stage 1
Page 97 of 124
7.2 APPENDIX B: DATA FLOWS AMONG BIONIC COMPONENTS AND TECHNOLOGIES IMPLEMENTING THE REQUIRED COMMUNICATION LINKS
Table 19: Data Flows among Bionic Components
Output Source
Data Monitoring
BIONIC EDGE BIONIC
Input Smart Applications Sensors… Research
AI Co-Processor device Bionic Storage Platform Physician Ergonomist Gamification Worker
Source Watch (under one web …. Data Base
Application Application
app)
Kinematic data,
RAW and
Kinetic data,
Notificati Processed
Physiological
ons Anonymiz
AI Co- data, Ergonomic Configurat
{Current x X ed Data X X X X
Processor Score ion Data
State, (SD Card
Computation,
Alerts} on the AI
Environmental
chip)
data, Alerts
Physiological Physiological
data{Heart Rate}, data{Heart Rate},
Environmental Biomechanical
Smart Data {Noise data Displays
X x X X X X X
Watch Level} {Acceleration, Notifications
Commands Angular Velocity}
{Start, Stop, Commands{Start,
Pause} Stop, Pause}
Body
Morphology
Kinematic data, Kinetic
Parameters,
data, Physiological data,
BIONIC Height, Weight,
Ergonomic Score Displays
EDGE device Gender, Fatigue X X X X X X X
Computation, Notifications
Application Level,
Environmental data,
Commands, User
Alerts, Work Session Task
settings,
Adaptive Settings
Data Stores his/her Personal Read only Read only
Access to all
Monitoring X X X X Data to the Bionic X shared data shared data X
worker's data
Applications Database, Training for workers for workers
Page 98 of 124
Output Source
Data Monitoring
BIONIC EDGE BIONIC
app)
(under one Preferences, User's
web app) Training Goals, Motivation
Profile (derived through a
set of questions) with the
assistance with the
IT/Admin, doctors'
suggestions and training
goals, Adaptive Settings
Sensor 1
Raw data {….} X X X X X X X X X
Name
Sensor 2
Raw data {….} X X X X X X X X X
Name
Sensor …n Raw data {….} X X X X X X X X X
The Gamification
The BIONIC web application
The Edge device platform retrieves from the
retrieves: Body retrieves from Ergonomic Score
Morphology the Database: Computation,
Parameters, Kinematic data, Age, Weight,
Bionic Height, Weight, Kinetic data, Height, Body
Storage X X Gender, Fatigue Physiological X X X X Morphology, X
Platform Level, data, Ergonomic Carried Load,
Commands, Score Fatigue (from the
User settings, Computation, AI chip),
Adaptive Environmental Motivation Level,
Settings data, Alerts, Training
Worker's Data Preferences,
Goals
Research
X X X X X X X X X X
Data Base
Set suggestions
and training
Physician X X X X X X X X X
goals, Adaptive
Settings
Page 99 of 124
Output Source
Data Monitoring
BIONIC EDGE BIONIC
app)
Set suggestions,
training goals
Ergonomist X X X X X X X X X
and Adaptive
Settings
The Gamification Notifications{Sc
Notificati
application stores its ore, Progress
BIONIC ons
results to the Database towards the
Gamification X {Current X X X x X X
(Fatigue level, Experience goal, Questions,
Application State,
Sampling, Activity Level, Advises, Alerts,
Alerts}
Score, Progress Goal) Exercises}
Stores his/her
Personal Data
to the Bionic
Database,
Training
Commands
Comman Preferences,
(Pair, Unpair, Experience
ds {Start, Goals,
Worker X Upload, Discard, X X X X X Sampling,
Stop, Motivation
Help, Work Nickname
Pause} Profile (derived
Session Task}
through a set of
questions) with
the assistance
with the
IT/Admin
Page 100 of 124

Table 20: Technologies Implementing the Required Communication Links
Data
BIONIC EDGE Monitoring BIONIC
AI Co- Smart Sensor Bionic Storage Research
Connections Smart Watch device Applications Physician Ergonomist Gamification Worker
Processor Hub Platform Data Base
Application (under one Application
web app)
AI Co-
X WiFI (TCP/IP) X USB X X X X X X
Processor
Smart Watch X X X Bluetooth X X X X Bluetooth Physically
BIONIC EDGE
WiFI WiFi/LTE
device X X X X X X X Physically
(TCP/IP) (HTTPS)
Application
Data
Monitoring
Applications X X X X HTTPS X HTTPS HTTPS X HTTPS
(under one
web app)
Sensor hub is
Smart Sensor connected via
USB Bluetooth X X X X X X X X
Hub cable with the
sensors
Bionic Storage Wifi/LTE
X X HTTPS X X X X WiFi(HTTPS) X
Platform (HTTPS)
Research Data
X X X X X X X X X X
Base
Physician X X X HTTPS X X X X X X
Ergonomist X X X HTTPS X X X X X X
BIONIC
WiFi
Gamification X Bluetooth X X X X X Physically
(HTTPS/LTE)
Application
Worker X Physically Physically HTTPS Physically X X X X Physically
Page 101 of 124

7.3 APPENDIX C: ELICITATION OF SECURITY AND PRIVACY REQUIREMENTS FOR THE BIONIC SYSTEM
Vulnerability Threat Threat /

Vulnerability Affected Assets Requirements
ID ID Attack
Man-in-the- • Ensure Data confidentiality during

TH-IOT-10 Stored Data, Transmitted Data (through WiFi or Bluetooth)
Middle transmission
• Ensure Data integrity during
Access point allowing Transmission
VU-CO-01
unlawful eavesdropping Abuse of • Ensure Worker’s Anonymity
TH-IOT-07 Stored Data • Unlinkability between BIONIC EDGE
personal data
device and the BIONIC storage
platform
Additional hardware
• Ensure that only legitimate devices
items can be fitted for Sensors Hardware, Smart Sensor Hub Hardware, AI Co-Processor
Modification of interact with the BIONIC system
VU-CO-02 storing, transmitting or TH-IOT-04 Hardware (AI chip), Smart Watch Hardware, Wired and USB
Hardware (ensure the validity of hardware
corrupting information communication Links
devices)
(e.g. physical keylogger).
Additional software can Back End BIONIC Storage Platform Application Server Software, Back • Ensure the origin and integrity of
be added for storing, End BIONIC Storage Platform Database Server Software (DBMS), Smart BIONIC firmware/software
VU-CO-03 transmitting or TH-IOT-02 Malware Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI • Ensure secure deployment of
corrupting information Co-Processor Firmware/Software, BIONIC EDGE device Application BIONIC firmware/software
(e.g. keylogger) Software, BIONIC Gamification Application Software, Stored Data • Ensure Worker’s Anonymity
Sensors Hardware, Smart Sensor Hub Hardware, AI Co-Processor

• Ensure the quality and the
Failures of Hardware (AI chip), Smart Watch Hardware, Back End BIONIC Storage
VU-CO-04 Ageing of the equipment TH-IOT-13 timeliness of the hardware
devices Platform Data Base Server Hardware, Back End BIONIC Storage Platform
maintenance services
Application Server Hardware, Wired and USB communication Links

Failures of Hardware (AI chip), Smart Watch Hardware, Back End BIONIC Storage • Ensure the quality of the hardware
VU-CO-05 Ageing of the medium TH-IOT-13
devices Platform Data Base Server Hardware, Back End BIONIC Storage Platform devices
Page 102 of 124


ID ID Attack

Middle transmission
Communication in Transmission
VU-CO-06
broadcast mode Abuse of • Ensure Worker’s Anonymity
personal data
platform

Equipment accessible to Modification of • Ensure that crucial hardware
VU-CO-07 TH-IOT-04 Hardware (AI chip), Smart Watch Hardware, Wired and USB
unauthorised persons Hardware devices are tamper proof
communication Links
Equipment sensitive to
electrical disturbances
VU-CO-08 (voltage drops, TH-IOT-13
overvoltages, transient
power-cuts)
Back End BIONIC Storage Platform Application Server Software, Back • Ensure the quality and the
End BIONIC Storage Platform Database Server Software (DBMS), Smart timeliness of the software
Equipment that is
Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI maintenance services
VU-CO-09 complex to use or not TH-IOT-14 Failure of system
Co-ProcessorFirmware/Software, Sensor's Firmware/Software, BIONIC • Ensure appropriate training /
user-friendly
EDGE device Application Software, BIONIC Gamification Application awareness programs for the BIONIC
Software users

VU-CO-10 Fragility of equipment TH-IOT-13

Incorrect operating Failures of Hardware (AI chip), Smart Watch Hardware, Back End BIONIC Storage • Ensure the quality of the hardware
VU-CO-11 TH-IOT-13
conditions devices Platform Data Base Server Hardware, Back End BIONIC Storage Platform devices
Page 103 of 124


ID ID Attack
• Ensure availability of the

communication channel
Incorrect sizing (e.g. too
Back End BIONIC Storage Platform Application Server Software, AI Co- • Ensure availability of required
VU-CO-12 much data for the TH-IOT-01 Denial of Service
ProcessorFirmware/Software, WiFI and Bluetooth communication Links hardware resources (processing
maximum passband)
power, storage space, memory
space)
Back End BIONIC Storage Platform Application Server Software, Back

End BIONIC Storage Platform Database Server Software (DBMS), Smart
Interface side effects
Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI • Ensure interoperability of BIONIC
VU-CO-13 (compatibility problems TH-IOT-14 Failure of system
Co-Processor Firmware/Software, Sensor's Firmware/Software, BIONIC software components
between protocols, etc.)
EDGE device Application Software, BIONIC Gamification Application
Software

Middle transmission
Interface with a function
Transmission
VU-CO-14 that allows
Abuse of • Ensure Worker’s Anonymity
eavesdropping TH-IOT-07 Stored Data
personal data • Unlinkability between BIONIC EDGE
platform

VU-CO-15 Maintenance fault TH-IOT-13 timeliness of the hardware

Media accessible to Failures of Hardware (AI chip), Smart Watch Hardware, Back End BIONIC Storage • Ensure that crucial hardware
VU-CO-16 TH-IOT-13
unauthorised persons devices Platform Data Base Server Hardware, Back End BIONIC Storage Platform devices are tamper proof
Medium and supports Man-in-the- • Ensure Data confidentiality during

VU-CO-17 TH-IOT-10 Stored Data, Transmitted Data (through WiFi or Bluetooth)
whose characteristics Middle transmission
Page 104 of 124


ID ID Attack
allow eavesdropping • Ensure Data integrity during

(e.g. Ethernet, wireless Transmission
communication systems) Abuse of • Ensure Worker’s Anonymity
TH-IOT-07 Stored Data
personal data • Unlinkability between BIONIC EDGE
platform

No accessible user Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI
VU-CO-18 TH-IOT-14 Failure of system timeliness of the software
support Co-Processor Firmware/Software, Sensor's Firmware/Software, BIONIC
Software
Man-in-the-
No authentication of TH-IOT-10 Stored Data, Transmitted Data (through WiFi or Bluetooth) • Ensure the authenticity of the
Middle
VU-CO-19 equipment connected to hardware components connected to
the network Abuse of the BIONIC system
personal data

Middle transmission
VU-CO-20 No physical protection • Ensure Data integrity during
Abuse of Transmission
personal data • Ensure Worker’s Anonymity
Man-in-the-
TH-IOT-10 Stored Data, Transmitted Data (through WiFi or Bluetooth) • Ensure that only authorised users
No robust access control Middle
VU-CO-21 can access the BIONIC system
system Abuse of
TH-IOT-07 Stored Data • Ensure Worker’s Anonymity
personal data

Failures of Sensors Hardware, Smart Sensor Hub Hardware, AI Co-Processor
VU-CO-22 Obsolete hardware TH-IOT-13 timeliness of the hardware
devices Hardware (AI chip), Smart Watch Hardware, Back End BIONIC Storage maintenance services
Page 105 of 124


ID ID Attack
Platform Data Base Server Hardware, Back End BIONIC Storage Platform
Man-in-the- • Ensure the authenticity of the

Physical access to TH-IOT-10 Stored Data, Transmitted Data (through WiFi or Bluetooth)
Middle hardware components connected to
communication support
the BIONIC system
or equipment allowing
VU-CO-23 • Ensure Worker’s Anonymity
eavesdropping Abuse of
equipment to be personal data device and the BIONIC storage
installed
platform
Man-in-the- • Ensure the authenticity of the

Physical or logical access Middle hardware components connected to
to a relay allowing the BIONIC system
VU-CO-24 eavesdropping • Ensure Worker’s Anonymity
equipment to be Abuse of • Unlinkability between BIONIC EDGE
installed personal data device and the BIONIC storage
platform

Poor equipment Failures of Hardware (AI chip), Smart Watch Hardware, Back End BIONIC Storage • Ensure the quality of the hardware
VU-CO-25 TH-IOT-13
reliability devices Platform Data Base Server Hardware, Back End BIONIC Storage Platform devices

Poor management of • Ensure the quality and the
Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI
VU-CO-26 pilot releases and TH-IOT-14 Failure of system timeliness of the software
Co-ProcessorFirmware/Software, Sensor's Firmware/Software, BIONIC
configurations maintenance services
Software

VU-CO-27 Poor medium reliability TH-IOT-13
Page 106 of 124


ID ID Attack

TH-IOT-02 Malware Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI • Ensure the origin and integrity of
Co-ProcessorFirmware/Software, BIONIC EDGE device Application BIONIC firmware/software
Software, BIONIC Gamification Application Software, Stored Data • Ensure secure deployment of
BIONIC firmware/software
Possibility of adding Back End BIONIC Storage Platform Application Server Software, Back
VU-CO-28 • Ensure the reliability and security of
software derivations End BIONIC Storage Platform Database Server Software (DBMS), Smart
Software the BIONIC software development
TH-IOT-15 Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI
vulnerabilities process (Security and Privacy by
Co-ProcessorFirmware/Software, BIONIC EDGE device Application
Design)
Software, BIONIC Gamification Application Software
• Ensure Worker’s Anonymity
Abuse of
personal data
• Ensure the authenticity of the

Sensors Hardware, Smart Sensor Hub Hardware, AI Co-Processor hardware components connected to
Possibility of circuit Modification of
VU-CO-29 TH-IOT-04 Hardware (AI chip), Smart Watch Hardware, Wired and USB the BIONIC system
derivation Hardware
communication Links • Ensure the quality of the hardware
devices
Man-in-the-
Possibility of corrupting Middle • Ensure availability of the
VU-CO-30
a communication Abuse of communication channel
personal data

Possibility of incorrect End BIONIC Storage Platform Database Server Software (DBMS), Smart
configuration, Failure of Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI
VU-CO-31 TH-IOT-14 timeliness of the software
installation or System Co-ProcessorFirmware/Software, Sensor's Firmware/Software, BIONIC
modification of relays EDGE device Application Software, BIONIC Gamification Application
Software
Page 107 of 124


ID ID Attack

Middle transmission
Possibility of interfering • Ensure Data integrity during
with data transmitted Transmission
VU-CO-32
via the communication Abuse of • Ensure Worker’s Anonymity
media TH-IOT-07 Stored Data • Unlinkability between BIONIC EDGE
personal data
platform
Possibility of remote TH-IOT-11 Session hijacking Stored Data

administration of the
• Ensure that only authorised users
VU-CO-33 system using non-
Abuse of can access the BIONIC system
encrypted TH-IOT-07 Stored Data
personal data
administration tools
TH-IOT-11 Session hijacking Stored Data

Possibility of remote • Ensure that only authorised users
VU-CO-34
system administration Abuse of can access the BIONIC system
personal data
Back End BIONIC Storage Platform Application Server Software, Back • Ensure the origin and integrity of
End BIONIC Storage Platform Database Server Software (DBMS), Smart BIONIC firmware/software
TH-IOT-02 Malware Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI • Ensure secure deployment of
Co-ProcessorFirmware/Software, BIONIC EDGE device Application BIONIC firmware/software
Possibility of remote
Software, BIONIC Gamification Application Software, Stored Data • Ensure the reliability and security of
VU-CO-35 system administration
the BIONIC software development
from any station
process (Security and Privacy by
Abuse of Design)
personal data • Ensure that only authorised users
can access the BIONIC system
Possibility of subjecting • Ensure availability of the

the relays to an Back End BIONIC Storage Platform Application Server Software, AI Co- communication channel
VU-CO-36 TH-IOT-01 Denial of Service
excessive number of ProcessorFirmware/Software, WiFI and Bluetooth communication Links
• Ensure availability of required
requests or intense hardware resources (processing
Page 108 of 124


ID ID Attack
interference (e.g. denial power, storage space, memory

of service attacks such space)
as smurfing, SYN flood
etc.)
Man-in-the- • Ensure availability of the

Middle communication channel
• Ensure availability of required
Targeted cyber hardware resources (processing
TH-IOT-06 Back End BIONIC Storage Platform Application Server Software
Presence of a attacks power, storage space, memory
communication network
Abuse of space)
VU-CO-37 with the outside TH-IOT-07 Stored Data
personal data • Ensure that only authorised users
allowing exchange of
information
• Ensure that abnormal network
Back End BIONIC Storage Platform Application Server Software, AI Co- activity (requests, traffic) can be
ProcessorFirmware/Software, WiFI and Bluetooth communication Links detected
Man-in-the-
TH-IOT-10 Stored Data, Transmitted Data (through WiFi or Bluetooth) • Ensure that only authorised users
Middle
Presence of protocol
Abuse of • Ensure Data confidentiality during
VU-CO-38 that has no TH-IOT-07 Stored Data
personal data transmission
authentication function
Back End BIONIC Storage Platform Application Server Software, AI Co- Transmission
ProcessorFirmware/Software, WiFI and Bluetooth communication Links
Protocol not allowing TH-IOT-11 Session hijacking Stored Data

safe authentication of
the sender of a Abuse of
TH-IOT-07 Stored Data • Ensure Worker’s Anonymity
communication personal data
Standard interface Man-in-the- • Ensure that only authorised users

allowing information Middle can access the BIONIC system
Page 109 of 124


ID ID Attack
exchanges (e.g. • Ensure Data confidentiality during

Bluetooth interface transmission
Abuse of
accepting all TH-IOT-07 Stored Data • Ensure Data integrity during
personal data
communications by Transmission
default) • Ensure Worker’s Anonymity

Device
TH-IOT-17 Hardware (AI chip), Smart Watch Hardware, Wired and USB • Ensure that crucial hardware
destruction
communication Links devices are tamper proof
• Ensure that only legitimate devices
The equipment can be Modification of interact with the BIONIC system
VU-CO-41 TH-IOT-04 Hardware (AI chip), Smart Watch Hardware, Wired and USB
accessed by everyone Hardware (ensure the validity of hardware
communication Links
devices)
Counterfeit by • Ensure that there is physical access
Stored Data, Transmitted Data (possible sources in this case are control to crucial BIONIC equipment
TH-IOT-08 malicious
considered only the Sensors Hardware and the Smartwatch hardware)
devices

The interfaces can be Abuse of
VU-CO-42 TH-IOT-07 Stored Data can access the BIONIC system
accessed by everyone personal data
Abuse of
personal data
Targeted cyber
TH-IOT-06 Back End BIONIC Storage Platform Application Server Software
attacks
The network makes it
Back End BIONIC Storage Platform Application Server Software, Back • Ensure that only authorised users
easy for unauthorised
VU-CO-43 End BIONIC Storage Platform Database Server Software (DBMS), Smart can access the BIONIC system
persons to use the
TH-IOT-02 Malware Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI • Ensure Worker’s Anonymity
resources
Software, BIONIC Gamification Application Software, Stored Data
Manipulation of
Information
Page 110 of 124


ID ID Attack
Back End BIONIC Storage Platform Application Server Software, AI Co-

ProcessorFirmware/Software, WiFI and Bluetooth communication Links
The relays identify

neither the sources nor • Ensure the authenticity of the
the destinations Man-in-the- hardware components connected to
(example of impact: Middle the BIONIC system
system vulnerable to • Ensure Worker’s Anonymity
spoofing attacks)

The supports and TH-IOT-02 Malware Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI
medium can be accessed Co-ProcessorFirmware/Software, BIONIC EDGE device Application
Software, BIONIC Gamification Application Software, Stored Data • Ensure that only authorised users
by everyone and are
active by default (e.g.
Abuse of • Ensure Worker’s Anonymity
RJ45 connectors TH-IOT-07 Stored Data
personal data
intermingled)
Manipulation of
Information
Manipulation of
Information
• Ensure the authenticity of the
Unidentified
VU-CO-46 Counterfeit by hardware components connected to
underground equipment Stored Data, Transmitted Data (possible sources in this case are
TH-IOT-08 malicious the BIONIC system
considered only the Sensors Hardware and the Smartwatch hardware)
devices

• Ensure appropriate training /
VU-CO-47 Users lack competency TH-IOT-14 Failure of system awareness programs for the BIONIC
users
Software
Page 111 of 124


ID ID Attack

Software that is complex Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI
VU-SO-01 TH-IOT-14 Failure of system awareness programs for the BIONIC
to use Co-ProcessorFirmware/Software, Sensor's Firmware/Software, BIONIC
users
Software

TH-IOT-02 Malware Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI
Software, BIONIC Gamification Application Software, Stored Data • Ensure the reliability and security of
Possibility of the
operating system being Back End BIONIC Storage Platform Application Server Software, Back
subjected to badly End BIONIC Storage Platform Database Server Software (DBMS), Smart
VU-SO-02 Software Design)
formed requests and TH-IOT-15 Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI
vulnerabilities • Ensure the quality and the
data (e.g. buffer Co-ProcessorFirmware/Software, BIONIC EDGE device Application
timeliness of the software
overflow) Software, BIONIC Gamification Application Software
Back End BIONIC Storage Platform Application Server Software, Sensor's
Manipulation of Firmware/Software, Smart Watch Firmware/Software, AI Co-
TH-IOT-03
software ProcessorFirmware/Software, BIONIC EDGE device Application

Use of an obsolete Software, BIONIC Gamification Application Software, Stored Data • Ensure the quality and the
VU-SO-03 version of the operating timeliness of the software
system or applications Back End BIONIC Storage Platform Application Server Software, Back maintenance services
Software
vulnerabilities
Page 112 of 124


ID ID Attack

TH-IOT-03

• Ensure recovery of crucial BIONIC
Single internally- Hardware (AI chip), Smart Watch Hardware, Back End BIONIC Storage
VU-SO-04 TH-IOT-16 Natural Disaster assets after natural disasters and
developed applications Platform Data Base Server Hardware, Back End BIONIC Storage Platform
other physical threats
Application Server Hardware

VU-SO-05 Lack of responsibility TH-IOT-14 Failure of system timeliness of the software
Software
• Ensure Data confidentiality of

Abuse of stored data
VU-SO-06 No encryption system TH-IOT-07 Stored Data
personal data • Ensure Data integrity of stored data
Software can be used by Abuse of • Ensure that only authorised users

everyone (e.g. no personal data can access the BIONIC system
VU-SO-07 password required for • Ensure that authorized users have
remote administration Back End BIONIC Storage Platform Application Server Software, AI Co- the correct privileges
of a workstation) ProcessorFirmware/Software, WiFI and Bluetooth communication Links • Ensure Worker’s Anonymity
• Ensure the reliability and security of

No restriction on Abuse of
VU-SO-08 TH-IOT-07 Stored Data process (Security and Privacy by
software entry points personal data
Design)
VU-SO-09 No implementation of TH-IOT-02 Malware Back End BIONIC Storage Platform Application Server Software, Back
basic security rules End BIONIC Storage Platform Database Server Software (DBMS), Smart
Page 113 of 124

ID ID Attack
applicable to the Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI

operating system and Co-ProcessorFirmware/Software, BIONIC EDGE device Application
software Software, BIONIC Gamification Application Software, Stored Data

End BIONIC Storage Platform Database Server Software (DBMS), Smart • Ensure the reliability and security of
Software the BIONIC software development
vulnerabilities process (Security and Privacy by
Software, BIONIC Gamification Application Software Design)
Back End BIONIC Storage Platform Application Server Software, Sensor's timeliness of the software
Manipulation of Firmware/Software, Smart Watch Firmware/Software, AI Co- maintenance services
TH-IOT-03
Abuse of
personal data

Software
vulnerabilities • Ensure the reliability and security of
Software, BIONIC Gamification Application Software the BIONIC software development
Use of non-evaluated
VU-SO-10 Back End BIONIC Storage Platform Application Server Software, Sensor's Design)
software
Manipulation of Firmware/Software, Smart Watch Firmware/Software, AI Co- • Ensure the quality and the
TH-IOT-03
software ProcessorFirmware/Software, BIONIC EDGE device Application timeliness of the software
Software, BIONIC Gamification Application Software maintenance services
Abuse of
personal data

VU-SO-11 TH-IOT-02 Malware • Ensure that authorized users have
the correct privileges
Page 114 of 124


ID ID Attack
Co-ProcessorFirmware/Software, BIONIC EDGE device Application • Ensure Worker’s Anonymity


No protection against End BIONIC Storage Platform Database Server Software (DBMS), Smart
Software
the use of advanced TH-IOT-15 Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI
vulnerabilities
privileges Co-ProcessorFirmware/Software, BIONIC EDGE device Application
Abuse of
personal data

Co-ProcessorFirmware/Software, BIONIC EDGE device Application • Ensure the reliability and security of
Software, BIONIC Gamification Application Software, Stored Data the BIONIC software development
Back End BIONIC Storage Platform Application Server Software, Back Design)
End BIONIC Storage Platform Database Server Software (DBMS), Smart • Ensure the quality and the
Possibility of modifying Software
TH-IOT-15 Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI timeliness of the software
VU-SO-12 or corrupting the vulnerabilities
Co-ProcessorFirmware/Software, BIONIC EDGE device Application maintenance services
software Software, BIONIC Gamification Application Software • Ensure the origin and integrity of
Back End BIONIC Storage Platform Application Server Software, Sensor's BIONIC firmware/software
Manipulation of Firmware/Software, Smart Watch Firmware/Software, AI Co- • Ensure secure deployment of
TH-IOT-03 BIONIC firmware/software
Software, BIONIC Gamification Application Software • Ensure Worker’s Anonymity
Abuse of
personal data

No sure means of Abuse of
VU-SO-13 TH-IOT-07 Stored Data can access the BIONIC system
identification personal data
Page 115 of 124


ID ID Attack
No procedure or system
• Ensure that authorized users have
for authorising Abuse of
VU-SO-14 TH-IOT-07 Stored Data the correct privileges
personnel to modify personal data
data
No monitoring of data Abuse of

VU-SO-15 TH-IOT-07 Stored Data • Ensure Data integrity of stored data
integrity personal data
No management of
• Ensure that authorized users have
profile privileges Abuse of
VU-SO-16 TH-IOT-07 Stored Data the correct privileges
(administrators, users, personal data
guest, etc.)

Possibility of installing a
backdoor or Trojan
VU-SO-17 TH-IOT-02 Malware Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI timeliness of the software
horse in the operating
Co-ProcessorFirmware/Software, BIONIC EDGE device Application maintenance services
system


Non-upgradable End BIONIC Storage Platform Database Server Software (DBMS), Smart
VU-SO-18 Software timeliness of the software
software TH-IOT-15 Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI
vulnerabilities maintenance services

TH-IOT-03
Page 116 of 124


ID ID Attack
Abuse of
personal data


Software
TH-IOT-15 Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI • Ensure the quality and the
VU-SO-19 Obsolete software vulnerabilities
Co-ProcessorFirmware/Software, BIONIC EDGE device Application timeliness of the software
Software, BIONIC Gamification Application Software maintenance services

TH-IOT-03
Abuse of
personal data

TH-IOT-02 Malware Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI • Ensure the reliability and security of
Co-ProcessorFirmware/Software, BIONIC EDGE device Application the BIONIC software development
Applications are not Software, BIONIC Gamification Application Software, Stored Data process (Security and Privacy by
VU-SO-20 checked before Design)
installation Back End BIONIC Storage Platform Application Server Software, Back • Ensure the quality and the
Software
TH-IOT-15 Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI maintenance services
vulnerabilities
Page 117 of 124


ID ID Attack

TH-IOT-03
Abuse of
personal data

Possibility of incorrect
configuration, • Ensure the quality and the
VU-SO-21 installation or TH-IOT-14 Failure of system timeliness of the software
modification of the maintenance services
operating system
Software

No systematic End BIONIC Storage Platform Database Server Software (DBMS), Smart
qualification procedure Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI
VU-SO-22 TH-IOT-14 Failure of system timeliness of the software
before installation or Co-ProcessorFirmware/Software, Sensor's Firmware/Software, BIONIC
updating EDGE device Application Software, BIONIC Gamification Application
Software

Lack of training in End BIONIC Storage Platform Database Server Software (DBMS), Smart
maintaining and Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI
VU-SO-23 TH-IOT-14 Failure of system awareness programs for the BIONIC
operating new Co-ProcessorFirmware/Software, Sensor's Firmware/Software, BIONIC
users
equipment EDGE device Application Software, BIONIC Gamification Application
Software

Possible side effects • Ensure the quality and the
VU-SO-24 after updating a TH-IOT-14 Failure of system timeliness of the software
software component maintenance services
Software
Page 118 of 124


ID ID Attack

Application requiring
End BIONIC Storage Platform Database Server Software (DBMS), Smart • Ensure availability of required
computing resources not
Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI hardware resources (processing
VU-SO-25 matched by the TH-IOT-14 Failure of system
Co-ProcessorFirmware/Software, Sensor's Firmware/Software, BIONIC power, storage space, memory
equipment (e.g.
EDGE device Application Software, BIONIC Gamification Application space)
insufficient RAM)
Software
TH-IOT-12 Network Outage WiFi
Back End BIONIC Storage Platform Application Server Software, AI Co- • Ensure availability of required
ProcessorFirmware/Software, WiFI and Bluetooth communication Links hardware resources (processing
No filter to protect the power, storage space, memory
VU-SO-26 system against Back End BIONIC Storage Platform Application Server Software, Back space)
saturation End BIONIC Storage Platform Database Server Software (DBMS), Smart • Ensure that abnormal network
Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI activity (requests, traffic) can be
Co-ProcessorFirmware/Software, Sensor's Firmware/Software, BIONIC detected
Software

Possible existence of
Back End BIONIC Storage Platform Application Server Software, Back • Ensure the reliability and security of
hidden functions
End BIONIC Storage Platform Database Server Software (DBMS), Smart the BIONIC software development
VU-SO-27 introduced during the Software
TH-IOT-15 Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI process (Security and Privacy by
design and development vulnerabilities
Co-ProcessorFirmware/Software, BIONIC EDGE device Application Design)
phase

TH-IOT-03
Page 119 of 124


ID ID Attack
Abuse of
personal data


Software retrieval from Software
vulnerabilities • Ensure the origin and integrity of
VU-SO-28 a non-authenticated Co-ProcessorFirmware/Software, BIONIC EDGE device Application BIONIC firmware/software
source Software, BIONIC Gamification Application Software

TH-IOT-03
Abuse of
personal data

Presence of residual
Abuse of the BIONIC software development
VU-SO-29 data used by the TH-IOT-07 Stored Data
personal data process (Security and Privacy by
software
Design)

Possibility of adding an • Ensure the reliability and security of
eavesdropping the BIONIC software development
VU-SO-30 TH-IOT-02 Malware Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI
programme such as a process (Security and Privacy by
Trojan horse Design)
VU-SO-31 TH-IOT-09 Brute force Back End BIONIC Storage Platform Application Server Software
Page 120 of 124


ID ID Attack
Password for accessing

the system or Abuse of • Ensure that only authorised users
application changed personal data can access the BIONIC system
rarely or not at all
Use of easily-observed
passwords to access the
Abuse of • Ensure that only authorised users
VU-SO-32 system or application TH-IOT-07 Stored Data
personal data can access the BIONIC system
(shape on keyboard,
short password)
The operating system TH-IOT-11 Session hijacking Stored Data

allows a session to be • Ensure that only authorised users
VU-OS-01
opened without Abuse of can access the BIONIC system
password personal data

TH-IOT-13
devices Platform Data Base Server Hardware, Back End BIONIC Storage Platform • Ensure the quality and the
Application Server Hardware, Wired and USB communication Links timeliness of the software
Back End BIONIC Storage Platform Application Server Software, Back maintenance services
VU-OS-02 No accessible support
Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI timeliness of the hardware
TH-IOT-14 Failure of system maintenance services
Software

TH-IOT-13 timeliness of the software
VU-OS-03 Insufficient competency Application Server Hardware, Wired and USB communication Links
Back End BIONIC Storage Platform Application Server Software, Back timeliness of the hardware
TH-IOT-14 Failure of system End BIONIC Storage Platform Database Server Software (DBMS), Smart maintenance services
Page 121 of 124

ID ID Attack

Software

TH-IOT-13
The operating system is • Ensure the quality and the
VU-OS-04 not checked before Back End BIONIC Storage Platform Application Server Software, Back timeliness of the software
installation End BIONIC Storage Platform Database Server Software (DBMS), Smart maintenance services
Software
Resource sharing makes Abuse of

TH-IOT-07 Stored Data • Ensure that authorized users have
it easy for unauthorised personal data
VU-OS-05 the correct privileges
persons to use the Manipulation of
TH-IOT-05 Stored Data, Transmitted Data (through WiFi or Bluetooth) • Ensure Worker’s Anonymity
system Information

Use of a standard Software, BIONIC Gamification Application Software, Stored Data
operating system on • Ensure the quality and the
VU-OS-06 which logical attacks timeliness of the software
have already been Software maintenance services
carried out vulnerabilities
Manipulation of Back End BIONIC Storage Platform Application Server Software, Sensor's
TH-IOT-03
software Firmware/Software, Smart Watch Firmware/Software, AI Co-
Page 122 of 124

ID ID Attack
ProcessorFirmware/Software, BIONIC EDGE device Application

Abuse of
personal data
TH-IOT-09 Brute force Back End BIONIC Storage Platform Application Server Software
Connection passwords • Ensure that only authorised users
VU-OS-07
not sufficiently complex Abuse of can access the BIONIC system
personal data
Back End BIONIC Storage Platform Application Server Software, Back • Ensure the quality and the
Possibility of creating or TH-IOT-02 Malware Sensor's Hub Firmware/Software, Smart Watch Firmware/Software, AI maintenance services
VU-OS-08 modifying system Co-ProcessorFirmware/Software, BIONIC EDGE device Application
commands Software, BIONIC Gamification Application Software, Stored Data
Abuse of process (Security and Privacy by
TH-IOT-07 Stored Data Design)
personal data
Page 123 of 124

Page 124 of 124

D1.4 Privacy and Data Protection Framework

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

D1.4 Privacy and Data Protection Framework

Uploaded by

Copyright:

Available Formats

This project has received funding from the European Union’s Horizon 2020 research and innovation

programme under Grant Agreement No 826304

Project Reference No 826304

Deliverable D1.4 Privacy and Data Protection Framework

Workpackage WP1: Overall Framework Definition

Dissemination Level RP (Restricted to other programme participants (including

Editor(s) Kalloniatis C (UPRC), Lambrinoudakis C (UPRC), Lyvas C.

Document Description The purpose of this deliverable is the description of a privacy

functional requirements but also of all non-functional (security

0.2 10.07.2019 Definition of the document’s structure C. Kalloniatis (UPRC)

0.3 15.07.2019 Description of the BIONIC System C. Kalloniatis (UPRC)

0.4 20.08.2019 Review on Privacy and eHealth Systems C. Lambrinoudakis (UPRC)

0.5 31.08.2019 GDPR and Privacy by Design C. Kalloniatis (UPRC)

0.6 20.09.2019 Privacy and Data Protection Framework – C. Kalloniatis (UPRC)

0.7 05.10.2019 Analysis of the proposed Data Protection C. Kalloniatis (UPRC)

0.8 13.10.2019 Description of the Privacy Impact C. Lambrinoudakis (UPRC)

E.L. Makri (UPRC)

0.9 5.12.2019 Application of stage 1 of the proposed C. Kalloniatis (UPRC)

1.0 07.12.2019 Application of stage 1 of the proposed C. Kalloniatis (UPRC)

Version Date Description Main author (unit)

1.1 08.12.2019 Application of stage 2. Formatting and C. Kalloniatis (UPRC)

E.L. Makri (UPRC)

1.2 17.12.2019 Application of stage 3. Formatting and C. Kalloniatis (UPRC)

E.L. Makri (UPRC)

4.3.4 Step 3: Security and Privacy Requirements ..................................................................... 86

Table 11: GDPR requirements derived from GAP analysis ..................................................................... 65

Table 12: Assets of the BIONIC System .................................................................................................. 68

Table 13: BIONIC Communication Channels .......................................................................................... 70

Table 14: BIONIC User Roles .................................................................................................................. 70

Table 15: BIONIC Security and Privacy Goals ......................................................................................... 71

Table 16: Threats against BIONIC assets ................................................................................................ 72

Table 19: Data Flows among Bionic Components .................................................................................. 98

Figure 3. GDPR- Significant changes for EU citizens’ data protection .................................................... 26

Figure 4. Associating GDPR approach with PriS Methodology ............................................................... 33

Figure 5. GDPR Compliant Personal Data Management Methodology .................................................. 36

Figure 6. Output of Stage 1.................................................................................................................... 37

Figure 7. Output of Stage 2.................................................................................................................... 39

Figure 8. Output of Stage 3.................................................................................................................... 41

Figure 9. Conceptual Framework of Impact Assessment ....................................................................... 43

Figure 10. Risks and Feared events........................................................................................................ 44

Figure 11. Factors used to estimate risks .............................................................................................. 44

Figure 12. Output of Stage 4.................................................................................................................. 45

Figure 18. Questionnaire for Supporting Stage 1................................................................................... 97

Term / Abbreviation Definition

1.1 PURPOSE OF THE DOCUMENT

1.2 STRUCTURE OF THE DOCUMENT

2 BIONIC SYSTEM AND USE CASES

2.1 BRIEF DESCRIPTION OF THE BIONIC SYSTEM

2.2 THE BIONIC DATA FLOW

Figure 1. The BIONIC data flow

• Kinematic data, probably at IMU sample rate (e.g. joint angles)

2.3 INTRODUCING PRIVACY IN BIONIC

2.4 END USERS AND USE CASE STORIES

Manny - Industry Manuel - Construction

Background Manny is a 55 years old male, working Manuel is a Spanish construction

Like many of his co-workers, Manny is Manuel is a bricklayer, involving the

Manny - Industry Manuel - Construction

computer experience, but he owns a

Introduction to Manny is invited for an introduction Manuel is invited for an introduction

Manny - Industry Manuel - Construction

feedback strategy provided by the feedback strategy provided by the

Manny - Industry Manuel - Construction