GDPR compliance through standard security controls: An automated approach

1.Introduction

The extensive proliferation of high-speed networks and the pervasiveness of the new connected technologies (e.g. IoT), demanding perpetual data exchange and the outsourcing of resources to service providers has markedly heightened the necessity for safeguarding personal information. Service Providers collect the data of their customers and could be able to profile very accurately each user, to offer personalized services and advertisements, but also abuse the collected information, going deep into the personal data of each customer. Consequently, in recent years, governments have established and enforced novel regulations to safeguard the private sphere of each person. Starting from 2018, the General Data Protection Regulation (GDPR) has been implemented in Europe, bestowing distinct rights upon every individual while introducing fresh protocols for personal data protection.

The GDPR delineates precise entitlements for each European citizen, with a particular emphasis on their control over personal data. For instance, individuals possess the right to ascertain the custodians of their personal information and to request its deletion. In accordance with the GDPR, service providers may engage in data processing without explicit consent only under specific circumstances as outlined in Articles 6, 9, and 10. They are also mandated to employ all requisite safeguards to ensure the security of such data and, in the event of a data breach, to promptly notify affected citizens.

The GDPR responds to a clear need to protect user data, today more exposed than before also because of the widespread use of social networks. However, an unintended consequence of these regulations is the revelation of the challenges faced by numerous legitimate enterprises, particularly small and medium-sized ones, in meeting these new mandates. The rights of a data subject (access, portability, deletion, …) imply that a service provider should be able to keep track of any reference to an individual in its data set. In order to perform such data traceability, requires the Small and Medium-Sized Enterprises (SME) to have their data precisely organized, which is often hard to design and enforce. Another relevant example concerns data protection and security measures. In some cases, (stated by Art. 35) the service provider is required to carry out a risk analysis process, by completing the Data Privacy Impact Assessment (DPIA) and selecting the remediation. However, conducting a DPIA is not an effortless analysis and, for a correct risk assessment, the data controllers must demonstrate that all the security measures available in the state of the art, both organizational and technical, have been adopted. One of the suggested measures is the acquisition of security certifications (e.g. ISO 27000 [29]), although these are often both expensive and not a sufficient guarantee that all the possible privacy problems have been addressed.

The approach outlined in this paper squarely focuses on a highly particular concern: the identification of necessary countermeasures for showcasing adherence to GDPR requirements. Our suggestion involves the utilization of NIST’s established security controls (SP 800-53 [31]), with the aim of offering a universally applicable solution.

As a result, this paper introduces the subsequent fresh and pioneering outcomes:

It must be clarified that this is an ICT technical paper, not a legal paper. In order to guarantee (fully) legal compliance to GDPR, there is both technical and legal work to do. This paper focuses on the technical aspects. However, it should be noted that the GDPR (which is a regulation and implies mainly the work of a lawyer to guarantee compliance), has a lot of requirements from a technical perspective, which are very hard to address for non-technical experts. Just as an example, no lawyer can compare anonymization algorithms measuring the k-anonymity level that they can assure. But every lawyer will be able to say that if you can reconstruct the identified person, the adopted anonymization algorithm is incorrect. Our methodology aims to offer a technical solution that synthesizes the checks to be done (using standard references), so that the lawyer will have all the necessary information to demonstrate needed to demonstrate the correctness and compliance of the technical solution to GDPR.

Given such a clarification, it is worth noticing that we are going to adopt security controls in order to address privacy issues. Privacy and Security are strictly connected, but they are different topics: privacy addresses the identification of acceptable data processing, and identifying the requirements for the system, which, in turn, implies (mostly) security requirements: Only authorized people are able to address data/resources (confidentiality); Data and resources can only be altered by authorized individuals in authorized manners, ensuring their integrity. Additionally, data and resources are accessible to authorized individuals as needed. Synthetically, Privacy addresses WHAT should be granted, Security addresses HOW to address such requirements.

Security Controls, which we will define in a more detailed way in Section 3 are the way that enables us to verify that Security requirements are being correctly fulfilled. Adoption of security controls to address even privacy issues is, nowadays, a common practice, as illustrated in the state of art [35,42], as an example, Italian National Cybersecurity framework (based on the NIST one) offers a profile for granting GDPR compliance, using as a reference framework the CIS Control framework (instead of the NIST one, as we made in this paper).

The paper is organized as follows: Section 2 outlines the existing challenges associated with GDPR adoption and privacy management, summarizing the findings and developments within the current state of the field. Section 3 describes the open issues, our proposed approach and the methodology behind the adoption of the standard NIST security controls to address GDPR compliance. Section 4 describes the tool we developed in order to implement such an approach. Section 5 describes a concrete case study and Section 6 summarizes the conclusions, presenting a set of future works.

2.Related works

The need to address compliance with the GDPR in a verifiable way and the correct adoption of security countermeasures capable of addressing privacy requirements is addressed by the standardization processes. In fact, a new ISO standard was recently issued, ISO/IEC 27701:2019 [30] which describes specific criteria for evaluating the GDPR. Additionally, the NIST’s Cybersecurity Framework [35] represents a step forward in integrating privacy issues with the security controls offered by security frameworks. The NIST Framework collects the controls offered by different frameworks into categories and, for specific categories (i.e. subcategories), it reports the related GDPR articles. Furthermore, the NIST SP-800-53 security control framework (draft version 5, officially released in September 2020), proposes a series of tables outlining the relation between security controls to privacy requirements. It is worth noting that the release 5 of the same special publication has completely changed the approach to privacy management compared to previous versions (revisions 3 and 4 proposed a set of privacy controls in a further appendix). Section 3.2 discusses privacy management in the NIST framework in further detail.

A compelling approach that integrates semantic methods for GDPR compliance is shown in [19,20]: the authors created a comprehensive and semantically enriched knowledge graph, often referred to as an ontology, to encompass the regulations imposed by both PCI DSS22 and the EU GDPR. The adopted approach reminds the one proposed within this work but differs in the type of the involved controls (PCI DSS instead of NIST Framework) and for a more explicit adoption of semantic techniques.

Another intriguing research direction can be found in [14,39], which aims to include rules related to GDPR into BPMN (Business Process Model and Notation). This augmentation is designed to support risk analysis procedures (e.g., [22,26]) and verification of compliance [27]. As detailed in Section 6, our goal is to integrate this approach with the one proposed here, mixing the semantic model, our conceptual map [7], and the use of standard security controls.

Another methodology, similarly grounded in ontologies, is presented in [38]. In this research, the authors introduce PrOnto, a tool designed to streamline the creation of legal knowledge related to privacy entities, data categories, processing activities, as well as entitlements and responsibilities. This is achieved through a methodology that combines legal theory analysis with ontological patterns.

In the work referenced as [13], they introduce an ontology-driven model aimed at encapsulating the data within PLAs. This allows various software tools to harness and manipulate this information for a range of applications, such as automating the discovery and comparison of service offerings.

A different approach to handling privacy requirements was studied by Rios et al. in [42]. They tried to use the ideas and outcomes from the MUSA project, which recommends a development process to meet security needs with Security Service Level Agreements. Their approach differs from the one presented in this paper because it mainly deals with Security SLAs and privacy, not compliance.

In [17], the authors suggest using ISO27000 controls to meet GDPR compliance. They pinpoint a set of controls in the ISO27000 framework and provide guidance on how to understand and apply them to adhere to GDPR rules. Although their approach resembles ours, they don’t explain the control selection process in detail, leaving some uncertainty about its thoroughness. Furthermore, they don’t offer support for automating the process or applying it in real-world GDPR compliance verification.

The same team explored GDPR compliance in different settings (public administration and crowdsourcing) using less formal techniques in [16] and in [15]. However, their method is distinct from ours as they analyze each GDPR article to propose changes to ISO 27001 and ISO 27002 standards to meet GDPR requirements.

To analyse the GDPR impact on research activities, there are many sources to read, and – not surprisingly – they are found in clinical scientific journals.

In order to enforce security measures for data processing, two different techniques can be used [12]:

The concept of pseudonymization is explored in greater detail in [34]. It’s important to note that the definition of pseudonymization is not meant to determine whether data qualifies as personal under the GDPR; it’s evident that data to which pseudonymization is applied still retains its status as personal data. In essence, pseudonymization should not be confused with anonymization. Instead, Recital 26 of the GDPR should be utilized to determine whether data qualifies as personal.

Additionally, practical illustrations that emphasize the contrast between anonymization and pseudonymization can be found in [36].

In the literature, there are also different approaches based on blockchain technology for GDPR compliance, mainly focusing on the monitoring of the activities affecting the users’ data than the enforcement of any preventive security measure. The authors of [5] proposed a formal model for supporting GDPR compliance checking from smart (IoT) devices based on smart contracts. The idea that there is behind is to track the operations carried out by a device on a distributed and immutable ledger to check whether it infringes user privacy.

In [4], The authors described a novel strategy based on encoding GDPR rules into smart contract opcodes. These operations are then recorded on a blockchain to enable auditing. They developed an abstract model to show how cloud service providers could use a blockchain-based virtual machine to access and carry out the smart contracts. Additionally, they presented a case study to exemplify their approach. Readers looking for more research on using blockchain for GDPR compliance management can explore further studies in [33] and [32].

In [28], the authors leveraged a machine learning approach to automate GDPR compliance checking. They develop specific methods to automate compliance checking of privacy policies, relying on NLP to extract data practices from privacy policies and then encoding GDPR rules to check the presence of mandatory information.

Authors of [6] proposed a framework for small and medium-sized enterprises based on a three-step methodology (analysis, design and implementation) and tested it empirically against three case studies.

In [41], the authors proposed a framework to test the compliance of Big Data systems, proposing a guideline for GDPR verification and implementation in Big Data systems. They translated GDPR requirements to IT Security requirements.

Furthermore, authors of [37] presented a proof-of-concept to detect infringements of privacy norms or to prevent possible violations using BPMN in the GDPR domain.

Finally, in [40], the authors describe a technique to automatically evaluate the compliance of the security policies of a system against formal rules derived from legal provisions.

The results described in [2,3] and [1], by the same research team, focus on the idea of Privacy Level Agreements (PLAs), proposed by the Cloud Security Alliance [8]. The authors propose a PLA metamodel in [2], relating together the concepts of privacy and security, trying to understand how to address GDPR rules with their model, in order to express both users needs and providers capabilities. In [1] the focus is moved to the risk analysis, to help users to identify their own requirements with respect to PLAs, whereas in [3] they try to assess the impact of the taken choices, identifying at the same time the standard security controls proposed by CCM (Cloud Control Matrix) [11].

It is worth noticing that the approach proposed by those authors differs from the vision we explore within this work: we focus on legal compliance, i.e. we try to help providers demonstrate compliance to GDPR, instead the above-cited papers focus more on the user’s requirements and their match with the providers’ offerings. The proposed PLA metamodel is a complementary effort with respect to our GDPR conceptual map [7]. Their risk and impact assessment could be in future compared with our approach based on NIST security controls (a map among NIST and CSA controls is available).

In the paper by Granata et al. [25], the authors detail an innovative approach that utilizes business processes, specifically Business Process Model and Notation (BPMN), to assess security and privacy. A goal of this approach is to automatically generate the GDPR treatment register, documenting data processing activities as mandated by GDPR.

In conclusion, there are many different approaches to assessing privacy compliance of software frameworks, due to new regulations and the new challenges given by the growth of ICT services, especially these days, in which many researchers are developing programs and apps devoted to the fight against Covid-19 pandemic, and in these tools, there are several critical aspects related to privacy. Therefore, it is of paramount importance to develop methodologies and tools that help researchers and companies to respect privacy constraints.

3.Compliance verification through standard security control

Verifying GDPR compliance can be quite a convoluted task and raises several issues, particularly for SMEs. To illustrate, consider Article 25, which requires that data processing comply with the principles set in Article 5 and requires the implementation of the privacy-by-design and privacy-by-default principles [10]. The GDPR outlines the limitations but does not offer any particular method to put them into practice. Instead, it gives the Data Controller the authority (and the responsibility) to choose the technical answers. In any case, the GDPR assumes that there is no way to absolutely guarantee that there won’t ever be a security breach and requires the data controller to take all reasonable precautions.

More specifically, Article 32 lists the requirements for processing security, while Article 33 cites the actions to be taken in the event of a data breach. The trade-off is that the Data Controller must prove they took all necessary steps to ensure the behavior was correct. To the best of the authors’ knowledge, there are no practical solutions in the state of the art, as stated in Section 2.

The approach we propose is based on the definition of a systematic security assessment process that can be clearly documented and whose compliance with the GDPR can be demonstrated. In order to be applicable, even by SMEs, the technique was built to require a limited effort by security experts, automating as much as possible the process activities. The solution proposed relies on the following concepts:

As a reference standard, the NIST security control framework [31] has been chosen, which is further detailed in the subsequent subsection.

Subsequently, a comprehensive analysis of the control framework has been conducted, meticulously mapping security controls to GDPR articles. The outcome of this phase is a NIST to GDPR article mapping table, which can be found in the Appendix, Table 7.

After all, has been implemented a simple procedure to identify the required security controls for each component of the infrastructure in order to document and evaluate the security policy for that infrastructure. As a result of this procedure, each component gets its own unique set of security restrictions.

4.Automatic definition of compliant security and privacy policies

The GDPR Conceptual Map and the Security controls mapping table constitute the ground data model respectively

Following our approach, a DPO professional implements the steps described in Fig. 1 to support Data Controllers and Data Processors. We assume that the Controller has already built the Record of Processing Activities (as imposed by article 30).44

Fig. 1.

GDPR compliance security assessment process.

During the first step of the process, the DPO should identify the assets within the target enterprise and indicate the processing activities in which each asset is involved. Section 5 describes these activities for a university that has multiple sites distributed on a large territory, composed of a central management system and many peripheral systems that manage (some of) the data. At this stage of the process, we assume that the DPO (and/or Data Controller) has identified both the data to protect and the infrastructure in terms of involved assets. Next, the security policy adopted by the administration must be defined. Note that, SMEs almost never define formally such a policy and, as a consequence, they can hardly demonstrate compliance and/or assess the security level of their own infrastructure.

The second step of the methodology addresses this issue: starting from the assets, the Data Controller and the DPO identify the GDPR articles that each subsystem is specifically subject to, depending on the locally processed data. It is worth noticing that, whenever the system is made of a single centralized system, the first two steps simply collapse in describing the hosting system and listing all the articles applied to it.

The final step, which is the most critical one, defines the security policy each asset of the target system should implement. As a starting point, note that a security policy is made of both organizational and technical countermeasures. As outlined in the previous section, security controls are classified by NIST in categories and we reported them in our table. Moreover, since we are interested in data protection, in our analysis we outlined which controls affect data-specific aspects, in order to help us in the selection. As a final result, the security policy will be a list of standard controls that each asset should implement and that could be verified through dedicated audits. Moreover, thanks to the classification of the controls, we subdivided the resulting security policy into two different lists of countermeasures, the technical ones, which we use as prescriptions for the technical staff, and the organisational ones, used as rules and criteria to be respected from an administrative point of view.

The procedure described relies on:

5.A case study: The GDPR in a university context

This section describes a concrete case study by applying the proposed approach for the GDPR-compliance of a University infrastructure. In particular, we refer to the University of Campania Luigi Vanvitelli for this case study, and accordingly, we briefly introduce the specific GDPR issues within a University context, then it is presented the approach to address them following the proposed methodology.

It should be noticed that the recent implementation of the GDPR caused significant concerns within the research and academic communities [18,34,43]. In short, the concern arises from the possibility that new data protection regulations might impede innovative research within the EU, potentially hindering research freedom. Scientific institutions often handle highly sensitive data, such as genetic, biometric, and health information. To address this, GDPR has a general prohibition on processing sensitive personal data (Article 9), although exceptions exist for research and archiving in the public interest (Articles 9 and 89). These exceptions cover data processing principles, data subject rights, and potential national implementations of scientific exceptions by member states [21].

Research institutions have voiced worries about the potential for fragmentation due to Member States’ exceptions. These exceptions could create unequal conditions for researchers and complicate research cooperation among Member States and globally. There are also questions about how the new data protection rules might affect international and global scientific research collaborations, especially concerning data sharing [21].

Moreover, GDPR article 89 states that processing for archiving purposes in the public interest, scientific research, historical or statistical purposes, shall be subject to appropriate safeguards to ensure data minimisation, i.e. data processing should only use as much personal data as is required to successfully accomplish a given task. The data minimisation principle may be achieved using the two different techniques named anonymization and pseudonomization as already seen in Section 2.

A recent study commissioned by the EU Parliament [21] on the comprehensive assessment of the expected impact of the GDPR on scientific research in Europe, pointed out many issues related to knowledge-based, technical, and regulatory aspects, and policy options are proposed. One of the issues is the lack of software tools to assess GDPR compliance that may assist universities and researchers.

5.2.System specification

The University of Campania is distributed in five cities, between the provinces of Naples and Caserta, as shown in Fig. 2. The whole network is composed of dark optical fibers, placed between the cities and, in each city, organized in a 48-fiber ring (see Fig. 3). The main data centre is placed in Naples, and the workstations of University researchers and clerks are placed in different buildings (for a total of 15) in each city.

Fig. 2.

The university network.

Fig. 3.

The university network: topology and components.

As outlined above, the application of GDPR to Universities poses new challenges, which are multiplied in this case by the distributed nature of our departments: in order to manage the ICT infrastructure, in fact, we have multiple organization domains, each of them involved in the maintenance and processing of different data. According to the methodology we proposed, the System Specification is the first step needed to guarantee that data are maintained in accordance with GDPR regulation. This implies i) building up the records of processing activities and ii) identify and list all the involved assets in the university infrastructure. As already outlined, the records of processing activities for Italian universities can be built in accordance with [9] and it is the first duty executed by our university DPO. In this work, to help readability, we restricted the analysis only to the processing activities for the students (chapter 5.2 of our Record of Processing Activities – RPA, [9] items 5.2.1 to 5.2.11). A summary of the main information contained in the RPA is shown in Table 4. As already outlined, in this analysis we focus only on such data and related processing activities.

Table 4

Record of processing activities – items related to students

Item	Purpose of processing
5.2.1	Study advisory service
5.2.2	Entrance exam
5.2.3	Student career (from first registration to degree)
5.2.4	Trainee-ship
5.2.5	Job placement
5.2.6	Fundraising, institutional communication
5.2.7	Statistics and teaching evaluation
5.2.8	Academic thesis publishing
5.2.9	Tutoring and social inclusion
5.2.10	Services for right of study
5.2.11	Disciplinary proceedings

In order to complete the first step we need to identify the core assets and to reduce the complexity of the problem and help the readability of the paper, we focused only on the technical assets in the ICT infrastructure. It should be considered that researchers, clerks and students may access most of the services from outside the university network. All the student services are served by a software framework, called esse3, produced by CINECA, a Consortium that builds and maintains software for the universities. The framework itself guarantees that:

• students may operate only on their own data

• professors may operate only on their own exam data

• clerks may operate on all data, depending on authorization given

According to such considerations, we briefly summarize our University ICT infrastructure in Fig. 3 which is a very simplified network scheme, the original one involves 22 different routers and a structured network for each different site. The sites are connected through a WAN fibre backbone and upstream to the Internet through the GARR55 national research network. However, the simplified scheme helps to easily identify that four kinds of components are involved in order to ensure security and GDPR compliance:

• The Server farm in which framework esse3 is running, and the framework itself

• The Firewall in university data centre

• The university Network

• The Workstations of clerks and professors

5.4.Per-asset policies

The last step of the proposed process aims at identifying the security controls that should be implemented by each of the assets of our system. Algorithm 1 describes the technique adopted to select all the controls, using the tables described in the previous sections. From the Table 5, referred as AssetTable we retrieved the list of the GDPR articles that each specific asset is responsible. Consequently, in the procedure, for each asset, we retrieved from the table 7 in Appendix, named GDPRTable in the pseudo-code, the full list of security controls (column 5) needed for each of the GDPR article (column 1) of the asset. We complete the procedure, removing the non-technical controls (that will be used for the administrative policies) and adding all the security control enhancements and (technical) related controls.

Algorithm 1

Procedure to derive the technical security controls

Executing the procedure for each of the assets in our system, we produced the Table 6, which is the (technical) security policy that should be assessed for each of the assets. It is worth noticing that we obtained a concrete security policy, that can be assessed by the university technicians and, at the same time, exposed to a third party to demonstrate adherence to GDPR procedures.

Table 6

Tool results

Component	Family	Controls	GDPR articles
Server	AC	AC-1, AC-3, AC-3(8), AC-3(11), AC-3(14), AC-16, AC-17, AC-17(2), AC-21	7, 25, 32
	AU	AU-1, AU-3, AU-3(3)	5, 18, 25
	CA	CA-1, CA-2	25
	MP	MP-1, MP-5, MP-6	15, 17
	PL	PL-8, PL-8(1), PL-8(2), PL-9	25
	PM	PM-1, PM-7, PM-9, PM-11, PM-23, PM-26, PM-20	5, 24, 25, 32
	SA	SA-8, SA-17	25
	SI	SI-1, SI-12, SI-12(1), SI-12(1), SI-12(2), SI-18, SI-19, SI-19(1), SI-20, SI-20(4)	5, 16, 17, 25, 32
	PT	PT-1, PT-4, PT-5, PT-6, PT-2, PT-3	5, 24
	PS	PS-8	24
Firewall	AC	AC-1, AC-17, AC-17(2)	32
	AU	AU-1, AU-3, AU-3(3)	5
	PM	PM-1, PM-9, PM-22, PM-23, PM-26	5, 24, 32
	SI	SI-1, SI-12, SI-12(1), SI-12(2), SI-18, SI-19, SI-20, SI-20(4)	5, 32
	PT	PT-4, PT-2, PT-3	5, 24
	PS	PS-8	24
Network	AC	AC-1, AC-17, AC-17(2)	32
	AU	AU-1, AU-3, AU-3(3)	5
	PM	PM-1, PM-9, PM-23, PM-26, PM-22	5, 24, 32
	SI	SI-1, SI-12, SI-12(1), SI-12(2), SI-18, SI-19, SI-20, SI-20(4)	5, 32
	PT	PT-4, PT-2, PT-3	5, 24
	PS	PS-8	24
Workstation	AC	AC-1, AC-17, AC-17(2)	32
	AU	AU-1, AU-3, AU-3(3)	5
	PM	PM-1, PM-9, PM-22, PM-23, PM-26	5, 24, 32
	SI	SI-1, SI-12, SI-12(1), SI-12(2), SI-18, SI-19, SI-20, SI-20(4)	5, 32
	PT	PT-4, PT-2, PT-3	5, 24
	PS	PS-8	24

6.Conclusions and future work

Demonstrating accountability to GDPR principles places a significant burden on enterprises, especially SMEs, in terms of time and cost. Furthermore, it calls for specific knowledge, including but not restricted to technological expertise in privacy and security.

This article focuses on the identification of appropriate countermeasures for demonstrating GDPR compliance within the context of GDPR implementation. This technical issue involves developing a security policy that not only ensures regulatory compliance but is also feasibly assessable.

We proposed and demonstrated a concrete methodology that in a semi-automated way identifies security controls and demonstrates compliance with GDPR indicating, for each GDPR article, how it was addressed by the security controls.

Processes for certification and security evaluation usually use standard security measures. They offer enough technical details for technical staff to adequately verify their proper execution.

The mapping’s effectiveness and the proposed approach were validated through its application in a real-world case study, specifically within our university infrastructure, where we successfully employed the technique.

This paper, starting from our previous work, a conceptual map of the GDPR and the relationships with the NIST standard security control framework introduced in [7], offers these concrete results:

This solution provides a valuable technical foundation for showcasing accountability and extends clear support to the Data Protection Officer (DPO), Data Controller, and Data Processor in verifying the proper implementation of security countermeasures.

One of the main limitations of this approach is the static mapping between the GDPR articles and the NIST SP-800-53 security controls. An update to the regulation or the release of new security controls would require the security expert to rework the mapping. A possible solution and further extension would be to leverage NLP (Natural Language Processing) techniques for dynamic construction. It would be interesting to develop an NLP technique in order to automatically map (or support the mapping) the GDPR articles and the NIST security controls.

A further extension would be to consider the organization controls included in the NIST SP-800-53 for accountability, as our methodology is currently focusing just on the technical controls.

We aim to extend the methodology in the future to support threat modelling [23,24] and risk analysis processes [26]. This task can be done by improving the tool that implements and automates the methodologies and integrating existing risk analysis tools, in order to relate the proposed countermeasures directly to the DPIA (Data Protection Impact Analysis) prescribed by the GDPR.

7.Acknowledgement

This work was partially supported by Project SSCeGov, funded by the University of Campania Luigi Vanvitelli, under Program VALERE.

Conflict of interest

The authors have no conflict of interest to report.