<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>i* to Support Personal Data Protection Compliance</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Jackeline Fernández</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Carolina Sacoto</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Karina Abad</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Juan Pablo Carvallo</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>CEDIA</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Cuenca</string-name>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Ecuador</string-name>
        </contrib>
      </contrib-group>
      <abstract>
        <p>As Information Systems become increasingly complex and ubiquitous, ensuring the security and privacy of personal data has become paramount. The need to protect individuals' privacy has led to the development of new laws and regulations, such as the General Data Protection Regulation in the European Union. This paper, presents an i* based approach to support Personal Data Protection compliance. The proposal makes use of the DHARMA method aimed at the definition of Enterprise Systems Architecture. Additional activities have been added to the method to thoroughly review dependencies in order to identify and categorize potential risks associated to personal data treated by them and analyze appropriate actions to mitigate their impact. The resulting method, DHARMA-PDP, helps organizations ensure compliance with existing regulations and implement best practices to protect personal data.</p>
      </abstract>
      <kwd-group>
        <kwd>1 DHARMA Method</kwd>
        <kwd>Personal Data Protection</kwd>
        <kwd>Information Systems</kwd>
        <kwd>Enterprise Systems Architecture</kwd>
        <kwd>Compliance</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1. Introduction</title>
      <p>Information Systems (IS) play a crucial role in our daily lives, facilitating automated interactions
between organizations and individuals. The advent of modern technologies such as smart devices,
cloud computing, artificial intelligence, and data analytics has made IS increasingly complex.
However, this complexity has also accelerated digital transformation, enabling businesses to offer
more efficient services by making data-driven decisions and simplifying transactions.</p>
      <p>
        Despite their benefits, the complexity and ubiquity of current IS pose significant challenges.
Personal Data Protection (PDP) has gained prominence as data collection and sharing continue to
expand. To protect individuals' privacy, laws and regulations like the General Data Protection
Regulation (GDPR) [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] have been established, while frameworks supporting data exchange aim
to strike a balance between privacy and the benefits of data sharing. Interoperability among
systems and technologies is also essential for this purpose. Therefore, developing robust
Enterprise Systems Architectures (ESA) that address these challenges is essential to support the
needs of businesses and individuals. ESA becomes crucial in identifying the types of data being
processed, as well as the data domain and subdomain owners within organizations, assessing
associated risks, and efficiently managing regulatory requirements and data subject demands to
avoid penalties and compensations.
      </p>
      <p>This paper proposes a method to support PDP based on the use of i* notation, focusing on how
dependencies can track owners responsible of specific data, and system components used for its
processing (legally known as data treatment). The DHARMA-PDP method proposed in this paper,
assists Data Protection Officers in timely fulfilling regulatory requirements and obligations.</p>
      <p>The document is structured as follows: Section 2 provides background information and related
work, section 3 presents the case study, section 4 presents the method and how it may support
the analysis for PDP compliance, and finally, section 5 presents conclusions and future work.</p>
    </sec>
    <sec id="sec-2">
      <title>2. Background and Related Work</title>
      <p>
        Organizations face significant challenges in correctly applying complex legal provisions for
personal data protection, especially with constant changes in processes, employees, services, and
technological platforms [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ][
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]. Challenges include updating data processing records,
implementing technical and organizational measures, and responding efficiently to data subject
requests [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ], all while facing resource and capability limitations for compliance [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]. To address
these issues, organizations need methods and management systems that facilitate regulatory
compliance [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ], enabling structured and documented processes to ensure proper application of
personal data protection regulations and timely compliance with regulatory requirements and
data subject demands [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ][
        <xref ref-type="bibr" rid="ref14">14</xref>
        ].
      </p>
      <p>
        Various methods and approaches, like Privacy by Design (PbD) [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ], Data Protection Impact
Assessment (DPIA) [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ][
        <xref ref-type="bibr" rid="ref17">17</xref>
        ], ISO 27001 [
        <xref ref-type="bibr" rid="ref18">18</xref>
        ], COBIT (Control Objectives for Information and
Related Technologies) [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ], and the NIST Privacy Framework [
        <xref ref-type="bibr" rid="ref20">20</xref>
        ], contribute to data protection
compliance, though not designed specifically for it. Despite these tools, efficiently addressing
compliance remains challenging, as existing methodologies focus exclusively on technical,
process-oriented, or legal approaches, overlooking the need for a multidisciplinary team with
technical, process, and legal expertise for comprehensive compliance [
        <xref ref-type="bibr" rid="ref22">22</xref>
        ][
        <xref ref-type="bibr" rid="ref23">23</xref>
        ].
      </p>
      <p>
        Previous research in software engineering emphasizes the importance of integrating data
protection principles into early stages of software development [
        <xref ref-type="bibr" rid="ref24">24</xref>
        ][
        <xref ref-type="bibr" rid="ref25">25</xref>
        ][
        <xref ref-type="bibr" rid="ref26">26</xref>
        ]. However,
translating these principles into requirements engineering activities remains challenging [
        <xref ref-type="bibr" rid="ref27">27</xref>
        ].
The lack of models, processes, and tools supporting privacy by design throughout the software
development life cycle, especially concerning the requirements of the General Data Protection
Regulation (GDPR), has been identified as a critical issue [
        <xref ref-type="bibr" rid="ref27">27</xref>
        ].
      </p>
      <p>
        To facilitate compliance with data protection regulations in requirements engineering,
interdisciplinary collaboration between software engineers and legal experts has been a solution,
but it can be expensive and time-consuming [
        <xref ref-type="bibr" rid="ref21">21</xref>
        ]. In response, this paper proposes a collaborative
method based on i* notation and the DHARMA method [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. The DHARMA method, extended with
activities specifically engineered to support PDP, encourages active participation of non-technical
stakeholders [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ][
        <xref ref-type="bibr" rid="ref4">4</xref>
        ][
        <xref ref-type="bibr" rid="ref5">5</xref>
        ][
        <xref ref-type="bibr" rid="ref6">6</xref>
        ][
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. This approach translates legal obligations into technical
requirements, empowering software engineers, promoting collaboration between legal experts
and engineers, and involving stakeholders throughout the organization. The resulting method
aims to ensure comprehensive compliance with data protection regulations, assisting
organizations in safeguarding privacy and data security in the ever-evolving digital landscape.
      </p>
    </sec>
    <sec id="sec-3">
      <title>3. Case Study</title>
      <p>CEDIA (Corporación Ecuatoriana para el Desarrollo de la Investigación y Academia) is a non-profit
organization that has been at the forefront of promoting the development of research and
academic activities in Ecuador since its inception. Established with the vision to foster a
collaborative network among Ecuadorian universities and research institutions, CEDIA has been
instrumental in driving technological innovation and academic excellence in the country.</p>
      <p>CEDIA's primary objective is to facilitate the sharing of knowledge and resources among its
member institutions, thereby enhancing the quality of education and research in Ecuador. It
achieves this by providing advanced network infrastructure, promoting collaborative research
projects, and offering a range of services such as cloud computing, digital repositories, and
elearning platforms.</p>
      <p>In an era where data is a valuable asset, CEDIA recognizes the importance of data protection
and privacy. As an organization that manages a significant amount of personal data, it is
imperative for CEDIA to ensure the highest standards of data protection. This is not only a legal
requirement under the Ecuadorian Personal Data Protection Law enacted in 2021, but also a
moral obligation to respect the privacy rights of individuals.</p>
      <p>Implementing data protection measures is crucial for CEDIA for several reasons. Firstly, it
helps to maintain the trust of its member institutions and the public. Secondly, it helps to prevent
potential legal and financial penalties that could result from non-compliance with PDP law. Lastly,
it contributes to the overall goal of creating a safe and secure digital environment for education
and research in Ecuador and sets a positive example for other organizations in the country.</p>
    </sec>
    <sec id="sec-4">
      <title>4. Method</title>
      <p>The complexity PDP analysis for compliance with regulations, commands advanced knowledge
in several fields, including technology, information systems, data analytics, governance, and
personal data protection law. Given this complexity, the proposed method mandates the
establishment of a multidisciplinary team of professionals. This team should comprise
representatives from each organizational area, possessing a thorough understanding of the
processes within their respective domains. For a holistic approach to PDP compliance, the team
should also include at least one information security technician and a legal professional
wellversed in data protection regulations. Their expertise will underscore the crucial aspects related
to legal compliance.</p>
      <p>Structure of CEDIA’s team included 18 professionals from 11 areas of the organization. 7
systems engineers, 6 lawyers, 2 business administrators, a communicator, an accountant and a
psychologist. 4 were managers, 2 mid-managers and the remaining operational personnel. In
addition, external advice was provided by two lawyers and a systems engineer certi ied in
information security and implementation of ISO 27001 and ISO 27701.</p>
      <p>
        To equip the team with the necessary skills and knowledge, basic training shall be provided in
data management, personal data protection regulations, and i* notation. In the case of CEDIA,
training was completed with guidelines based on the lessons presented in [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ][
        <xref ref-type="bibr" rid="ref7">7</xref>
        ], ensuring a
comprehensive understanding of the subject matter.
      </p>
      <p>
        To guide the process in a systematic way, the method proposes the use the four activities in
the DHARMA method [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ] as basic steps. This method aims to the definition of Enterprise Systems
Architectures (ESA) using the i* notation. The theoretical bases to support the method in the
analysis of enterprise context, structure and strategy, are two models defined by Porter’s models
of the market forces and value chain [
        <xref ref-type="bibr" rid="ref28">28</xref>
        ]. The activities in the DHARMA method are:
• Activity 1. Modelling the enterprise context: The organization and its strategy are analyzed
to identify its role within the context, defining Context Actors (CA) in relation to marked forces
and Organizational Areas (OA) in relation to value chain primary and supporting activities. At
the end of this activity i* SD models are built, to describe the context and scope of the
organization (CM).
• Activity 2. Modelling the environment of the system: In this activity, the impact of a
systemto-be is analyzed by identifying dependencies in CM, that can be partially or fully satisfied
(automated) by system services. The result is an i* SD model representing the system's ability
to fulfill dependencies related to different CAs or OAs.
• Activity 3. Decomposition of system goals: Dependencies included in the CM are analyzed
and decomposed into a hierarchy of intentional elements required to satisfy them. These
elements depict the services that the system must provide (functional requirements) as well
as restrictions on them (non-functional requirements). An i* SR diagram for the system is built.
• Activity 4. Identification of system architecture: This activity includes the identification of
System Actors (SA), which represent atomic software domains. Intentional elements identified
in Activity 3 are analyzed and semantically grouped. Each aggrupation reveals the services
that are expected to be provided by SA structuring them.
      </p>
      <p>
        The assessment identified a total of 178 CA and 11 OA and 2119 dependencies, see Table 1 for
some indicators in relation to resulting CM. 112 processes are required for the provision of the
64 services included in CEDIAS service package. 116 software tools (SA) integrate CEDIA’s ESA
and are used for their provision. Due to the magnitude of the model, a tabular representation was
adopted following the guidelines presented in [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] (see table 2 for an excerpt).
      </p>
      <p>The activities of the method allow for the systematic and precise identification of CAs, OAs, SA
and intentional elements e.g., dependencies, and establishes the “ideal” ESA and its services as
basis for PDP analysis. However, additional steps are required to complete PDP compliance
process. Method got extended with 5 additional activities in a framework called DHARMA-PDP:
• Activity 5. Reverse mapping of existing systems: This activity can be applied in forward or
reverse engineering. In the first case ESA describes the requirements of the system-to-be and
the software components needed for its implementation, those to be acquired (e.g., FOOS,
COTS or Services) and those to be built from the scratch. In the second case, when ESA is
already implemented and multiple software components are up and running, a reverse
engineering mapping is required to relate system components in operation to SA and their
expected services. This helps to identify unimplemented, unnecessary, or augmentable
services in relation to ESA. Additionally, it entails identifying new requirements for software
components integration and, analyzing and optimizing personal data shared among them. As
an example, in the case of CEDIA, the analysis proved that some software components, namely
ERP and Management SA, used in 34 and 54 out of the 112 processes accounted in table 1,
required signi icant improvements on their integration.
• Activity 6. Analysis of data associated to dependencies: Activity 6 involves a thorough
analysis of each identified dependency included in CM, to determine the specific data
associated with them, particularly personal data. In typical ESA implementation cases, UML
use cases and class diagrams can be used for this task. However, in CEDIA's case, since ESA
was already implemented, representatives from OA and other project team experts examined
system interfaces and processes to identify the data treated, particularly personal information.
A total of 915 dependencies were identified treating personal and sensitive data (see Table 1).</p>
      <p>Table 2 provides an excerpt of personal data associated with certain dependencies in CM.
• Activity 7. Data protection categorization: This activity involves data protection
categorization, where identified data types are mapped to corresponding categories defined
in the PDP law applicable in the territory. In the case of Ecuador, these categories include
personal identification, special categories (e.g., sensitive, data of children and adolescents,
persons with disabilities, credit-related), personal characteristics, social status, academic and
professional, employment, and economic, financial, and insurance data. A total of 106 out of
915 dependencies identified in activity 6 were marked critical in this activity.
• Activity 8. Risk and impact analysis: Following with the method, activity 8 involves
conducting a qualitative risk analysis to assess the potential impact on the organization,
considering the PDP Law applicable in the territory. This analysis identifies threats,
vulnerabilities, impact, and likelihood of occurrence.</p>
      <p>Qualitative risk analysis at CEDIA showed that, 23 out of 106 dependencies identified in
activity 7, required a Data Protection Impact Assessment (DPIA). The DPIA analyzed data
related to dependencies in relation to a checklist containing 44 risks, 20 security, 20 legal, and
4 international data transfer. The checklist was constructed considering the risks suggested in
standards and legal bodies such as ISO 27001, 27702 and GDPR. Figure 1 shows the risk map
resulting from the activity. Data associated to a dependency can be subject to multiple risks.
• Activity 9. Mitigation strategy definition: Finally, mitigation strategies must be defined for
each of the risks falling outside an acceptable threshold, starting for the most critical ones.
These strategies shall be designed to reduce the impact or likelihood of the risks, thereby
enhancing the organization's data protection posture. In CEDIA’s case, controls have also been
selected from those suggested by ISO 27001, ISO 27701, and GDPR, according to the
corresponding data processing activities. For instance, measures in relation to personal data
associated to dependencies in the occupational health and safety field included, the
establishment of a consent document allowing the process of health data and the definition of
time limits for periods for which data had to be preserved. The dependencies of CEDIA's core
areas (e.g., ICT) were given priority over others less critical such as Digital Printing.</p>
    </sec>
    <sec id="sec-5">
      <title>5. Conclusions and Future Work</title>
      <p>The study presented in this paper has demonstrated the application of the i* notation to support
Personal Data Protection compliance. The proposal makes use of the DHARMA-PDP method,
which allows for a systematic and precise identification of Context Actors, Organizational Areas,
intentional elements (e.g., dependencies) and System Actors, structuring the “ideal” Enterprise
Systems Architecture (ESA) and its services. However, the benefits go far beyond this scope.
DHARMA-PDP also help Data Protection Officers in fulfilling data subjects' requirements and
meeting regulatory obligations, identifying personal data, categorizing risks associated to them
and analyzing mitigation strategies, required to comply with existing regulations and implement
best practices to protect personal data.</p>
      <p>It is acknowledged that there are some threats to validity in this study. One of the main threats
is the potential for bias in the qualitative risk analysis conducted in activity 8. This analysis relies
on the expertise and judgement of the individuals conducting the assessment. Additionally, the
study is limited to the context of CEDIA and Ecuador, and may not be generalizable to other
organizations or contexts.</p>
      <p>However, based in the results of this study, the DHARMA-PDP method has shown its potential
in supporting organizations to ensure compliance with existing regulations and implement best
practices to protect personal data. Future work will focus on refining the method and expanding
its application to other contexts to further validate its effectiveness.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <surname>Regulation</surname>
          </string-name>
          (EU)
          <year>2016</year>
          /
          <article-title>679 of the European Parliament and of the Council of 27 April 2016</article-title>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <surname>Carvallo</surname>
            ,
            <given-names>J.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Franch</surname>
            ,
            <given-names>X.</given-names>
          </string-name>
          <article-title>On the Use of i* for Architecting Hybrid Systems: A Method and an Evaluation Report</article-title>
          .
          <source>Proceedings of PoEM</source>
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <surname>Carvallo</surname>
            ,
            <given-names>J. P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Franch</surname>
            ,
            <given-names>X.</given-names>
          </string-name>
          <article-title>Building Strategic Enterprise Context Models with i*: A Pattern-Based Approach</article-title>
          .
          <source>Proceedings of TEAR</source>
          <year>2012</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <surname>Carvallo</surname>
            ,
            <given-names>J.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Franch</surname>
            ,
            <given-names>X. Lessons</given-names>
          </string-name>
          <article-title>Learned on the use of i* by Non-Technical Users</article-title>
          . iStar
          <year>2014</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <surname>Abad</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Carvallo</surname>
            ,
            <given-names>J.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Peña</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          <article-title>iStar in Practice: On the identification of reusable SD Context Models Elements</article-title>
          .
          <source>Proceedings of iStar</source>
          <year>2015</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <surname>Abad</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Pérez</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Carvallo</surname>
            ,
            <given-names>J. P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Franch</surname>
            ,
            <given-names>X.</given-names>
          </string-name>
          <article-title>i* in Practice: Identifying Frequent Problems in its Application</article-title>
          .
          <source>Proceedings of ACM SAC</source>
          <year>2017</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <surname>Carvallo</surname>
            ,
            <given-names>J.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Franch</surname>
            ,
            <given-names>X.:</given-names>
          </string-name>
          <article-title>An empirical study on the use of i* by non-technical stakeholders: the case of strategic dependency diagrams</article-title>
          .
          <source>Requirements Engineering Journal</source>
          . Vol.
          <volume>24</volume>
          , pp.
          <fpage>27</fpage>
          -
          <lpage>53</lpage>
          (
          <year>2019</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <given-names>S.</given-names>
            <surname>Sirur</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J. RC.</given-names>
            <surname>Nurse</surname>
          </string-name>
          , and
          <string-name>
            <given-names>H.</given-names>
            <surname>Webb</surname>
          </string-name>
          . “
          <article-title>Are we there yet? Understanding the challenges faced in complying with the General Data Protection Regulation (GDPR)”</article-title>
          .
          <source>Proceedings of MPS</source>
          <year>2018</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <given-names>M.</given-names>
            <surname>Smith</surname>
          </string-name>
          and
          <string-name>
            <surname>J. Palmer. “</surname>
          </string-name>
          <article-title>ANALYSIS: Three Years Later, GDPR Compliance Still a Challenge”</article-title>
          . https://news.bloomberglaw.com/bloomberg-law
          <article-title>-analysis/analysis-three-years-later-gdprcompliance-still-a-challeng</article-title>
          . (
          <year>2021</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <given-names>M.</given-names>
            <surname>Saltarella</surname>
          </string-name>
          , G. Desolda,
          <string-name>
            <given-names>R.</given-names>
            <surname>Lanzilotti</surname>
          </string-name>
          ,
          <article-title>"Privacy Design Strategies and the GDPR: A Systematic Literature Review"</article-title>
          ,
          <source>HCI for Cybersecurity, Privacy and Trust</source>
          , vol.
          <volume>12788</volume>
          , pp.
          <fpage>241</fpage>
          , (
          <year>2021</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <given-names>M.</given-names>
            <surname>Bańka</surname>
          </string-name>
          , et. Al.,
          <article-title>"Practical Methods of Implementation for the Indispensable Mechanism of GDPR Compliance"</article-title>
          ,
          <source>Wroclaw Review of Law, Administration &amp; Economics</source>
          , vol.
          <volume>0</volume>
          , no.
          <issue>0</issue>
          , (
          <year>2022</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [12]
          <string-name>
            <given-names>D.F.</given-names>
            <surname>Martínez-Martínez</surname>
          </string-name>
          .
          <article-title>“Unification of personal data protection in the European Union: Challenges and implications”</article-title>
          . Profesional De La información,
          <volume>27</volume>
          (
          <issue>1</issue>
          ),
          <fpage>185</fpage>
          -
          <lpage>194</lpage>
          . (
          <year>2018</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [13]
          <string-name>
            <given-names>Y. -S.</given-names>
            <surname>Martin</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Kung</surname>
          </string-name>
          ,
          <article-title>"Methods and Tools for GDPR Compliance Through Privacy and Data Protection Engineering,"</article-title>
          .
          <source>Proceedings of EuroS&amp;PW</source>
          <year>2018</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [14]
          <string-name>
            <given-names>C.</given-names>
            <surname>Lambrinoudakis</surname>
          </string-name>
          . “
          <article-title>The General Data Protection Regulation (GDPR) Era: Ten Steps for Compliance of Data Processors and Data Controllers”</article-title>
          .
          <source>Proceedings of TrustBus</source>
          <year>2018</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [15]
          <string-name>
            <given-names>B.</given-names>
            <surname>Mashaly</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Selim</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A. H.</given-names>
            <surname>Yousef</surname>
          </string-name>
          ,
          <string-name>
            <surname>K. M. Fouad</surname>
          </string-name>
          ,
          <article-title>"Privacy by Design: A Microservices-Based Software Architecture Approach"</article-title>
          .
          <source>Proceedings of MIUCC</source>
          <year>2022</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          [16]
          <string-name>
            <surname>Party</surname>
          </string-name>
          , Data Protection Working.
          <article-title>"Guidelines on data protection impact assessment (DPIA) and determining whether processing is “likely to result in a high risk” for the purposes of Regulation 2016/679 (WP29</article-title>
          ).
          <source>Artic. 29 Data Prot. Work. Party. WP 248 rev 22</source>
          (
          <year>2017</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          [17]
          <string-name>
            <surname>Wright</surname>
          </string-name>
          ,
          <string-name>
            <surname>David</surname>
          </string-name>
          , et al.
          <article-title>"Integrating privacy impact assessment in risk management."</article-title>
          <source>International Data Privacy Law 4.2</source>
          (
          <issue>2014</issue>
          ),
          <fpage>pp155</fpage>
          -
          <lpage>170</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          [18]
          <string-name>
            <given-names>I. M.</given-names>
            <surname>Lopes</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            <surname>Guarda</surname>
          </string-name>
          and
          <string-name>
            <given-names>P.</given-names>
            <surname>Oliveira</surname>
          </string-name>
          ,
          <article-title>"How ISO 27001 Can Help Achieve GDPR Compliance,"</article-title>
          .
          <source>Proceedings of CISTI</source>
          <year>2019</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          [19]
          <string-name>
            <given-names>VM.</given-names>
            <surname>Orrego</surname>
          </string-name>
          .
          <article-title>"La gestión en la seguridad de la información según Cobit</article-title>
          ,
          <source>Itil e Iso 27000." Revista Pensamiento Americano 4.6</source>
          (
          <year>2013</year>
          ):
          <fpage>21</fpage>
          -
          <lpage>23</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          [20]
          <string-name>
            <given-names>J.S.</given-names>
            <surname>Hiller</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.S.</given-names>
            <surname>Russell</surname>
          </string-name>
          .
          <article-title>"Privacy in crises: The NIST privacy framework</article-title>
          .
          <source>" Journal of Contingencies and Crisis Management 25.1</source>
          (
          <year>2017</year>
          ):
          <fpage>31</fpage>
          -
          <lpage>38</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          [21]
          <string-name>
            <given-names>F.</given-names>
            <surname>Ciclosi</surname>
          </string-name>
          ,
          <string-name>
            <given-names>F.</given-names>
            <surname>Massacci</surname>
          </string-name>
          .
          <article-title>"The Data Protection Officer: A Ubiquitous Role That No One Really Knows"</article-title>
          ,
          <source>IEEE Security &amp; Privacy</source>
          , vol.
          <volume>21</volume>
          , no.
          <issue>1</issue>
          , pp.
          <fpage>66</fpage>
          -
          <lpage>77</lpage>
          ,
          <year>2023</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          [22]
          <string-name>
            <given-names>J.</given-names>
            <surname>Fernandes</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Machado</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L.</given-names>
            <surname>Amaral</surname>
          </string-name>
          .
          <article-title>"Identifying critical success factors for the General Data Protection Regulation implementation in higher education institutions"</article-title>
          ,
          <source>Digital Policy, Regulation and Governance</source>
          , Vol.
          <volume>24</volume>
          No.
          <issue>4</issue>
          , pp.
          <fpage>355</fpage>
          -
          <lpage>379</lpage>
          . (
          <year>2022</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          [23]
          <string-name>
            <given-names>A.</given-names>
            <surname>Tsohou</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Magkos</surname>
          </string-name>
          ,
          <string-name>
            <given-names>H.</given-names>
            <surname>Mouratidis</surname>
          </string-name>
          ,
          <string-name>
            <given-names>G.</given-names>
            <surname>Chrysoloras</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L.</given-names>
            <surname>Piras</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Pavlidis</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Debussche</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Rotoloni</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B.</given-names>
            <surname>Gallego-Nicasio</surname>
          </string-name>
          <string-name>
            <surname>Crespo</surname>
          </string-name>
          ,
          <article-title>"Privacy, Security, Legal and Technology Acceptance Requirements for a GDPR Compliance Platform"</article-title>
          ,
          <source>Computer Security</source>
          , vol.
          <volume>11980</volume>
          , pp.
          <fpage>204</fpage>
          ,
          <year>2020</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>
          [24]
          <string-name>
            <surname>Sartoli</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          <string-name>
            <surname>Ghanavati</surname>
            and
            <given-names>A.</given-names>
          </string-name>
          <string-name>
            <surname>Siami Namin</surname>
          </string-name>
          ,
          <article-title>"Towards Variability- Aware Legal-GRL Framework for Modeling Compliance Requirements,"</article-title>
          .
          <source>Proceedings of ESPRE</source>
          <year>2020</year>
          ,.
        </mixed-citation>
      </ref>
      <ref id="ref25">
        <mixed-citation>
          [25]
          <string-name>
            <given-names>S.</given-names>
            <surname>Ghanavati</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Rifaut</surname>
          </string-name>
          ,
          <string-name>
            <given-names>E.</given-names>
            <surname>Dubois</surname>
          </string-name>
          and
          <string-name>
            <given-names>D.</given-names>
            <surname>Amyot</surname>
          </string-name>
          ,
          <article-title>"Goal-oriented compliance with multiple regulations,"</article-title>
          <source>Proceedings of RE</source>
          <year>2014</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref26">
        <mixed-citation>
          [26]
          <string-name>
            <given-names>A.</given-names>
            <surname>Siena</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Perini</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Susi</surname>
          </string-name>
          and
          <string-name>
            <given-names>J.</given-names>
            <surname>Mylopoulos</surname>
          </string-name>
          ,
          <article-title>"Towards a framework for law-compliant software requirements"</article-title>
          .
          <source>Proceedings of ICSE</source>
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref27">
        <mixed-citation>
          [27]
          <string-name>
            <given-names>V.</given-names>
            <surname>Camargo</surname>
          </string-name>
          , et. Al.
          <article-title>Privacy by Design and Software Engineering: A Systematic Literature Review</article-title>
          .
          <source>Proceedings of SBQS '22.</source>
        </mixed-citation>
      </ref>
      <ref id="ref28">
        <mixed-citation>
          [28]
          <string-name>
            <given-names>M.</given-names>
            <surname>Porter</surname>
          </string-name>
          , “Competitive Strategy”. Free Press, New York, NY,
          <string-name>
            <surname>United</surname>
            <given-names>States</given-names>
          </string-name>
          ,
          <year>1980</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>