Extending PriPoCoG: A Privacy Policy Editor for GDPR-Compliant

Privacy Policies

Jens Leicht and Maritta Heisel

Paluno - The Ruhr Institute for Software Technology, University of Duisburg-Essen, Germany

Keywords:

GDPR, Compliance, Privacy Policies, Tool, Editor.

Abstract:

Privacy policies are an important tool for service providers around the world, especially after the enactment of

the General Data Protection Regulation (GDPR). Such privacy policies are commonly expressed in long texts

written in legalese. In many cases multiple departments of a company are involved in the deﬁnition of these

policies; however, only the legal department is able to evaluate the level of GDPR-compliance. We propose and

evaluate a privacy policy editor that can be operated by a broader audience. Our editor provides policy authors

with guidance on what information to include in a policy. Using the Prolog Layered Privacy Language (P-

LPL) our editor can also perform GDPR-compliance checks and warn policy authors when compliance issues

arise during policy deﬁnition. The privacy policies created with our editor are well structured and computer-

interpretable as we use an existing policy language (P-LPL). This may also be beneﬁcial for the data subjects,

who will be reading the privacy policies, as user interfaces can visualize the policies in structured and better

comprehensible ways, compared to the pure legalese texts of today’s privacy policies. Data controllers and

data processors may also use our editor for deﬁning service level agreements.

1 INTRODUCTION

Although privacy policies are important in the con-

text of compliance with data protection legislation,

the development of tools for improving privacy poli-

cies has been lacking. Legislations, such as the Gen-

eral Data Protection Regulation (GDPR) of the Euro-

pean Union (European Parliament and Council of the

European Union, 2016), require service providers to

inform end-users/data subjects about data collection

and processing in a transparent manner. A popular

solution to achieve this transparency is the use of pri-

vacy policies.

Such policies are written in a complex legalese,

which the end-users can hardly comprehend. Multiple

departments of a company might be involved in the

process of deﬁning a privacy policy and only the le-

gal department is able to evaluate the level of GDPR-

compliance.

We developed a privacy policy editor that inte-

grates into the Privacy Policy Compliance Guidance

framework (PriPoCoG) and provides feedback con-

cerning GDPR-compliance during the policy deﬁni-

tion (Leicht et al., 2022). This feedback enables

https://orcid.org/0000-0002-3275-2819

all departments to evaluate the GDPR-compliance of

their currently deﬁned privacy policy. Only at the end

of the deﬁnition process, the legal department should

review the resulting privacy policy.

Our editor not only improves the policy deﬁni-

tion process, but also provides beneﬁts for the end-

users/data subjects. The use of the Prolog Layered

Privacy Language (P-LPL) results in structured pri-

vacy policies, that can be visualized in different ways,

which can improve data subjects’ comprehension of

the policy. In combination with privacy-policy-based

access control (P2BAC) both sides of the privacy pol-

icy, service providers as well as data subjects, beneﬁt

from privacy policies created with our editor (Leicht

and Heisel, 2023). Our privacy policy editor can also

be used to express service level agreements (SLAs)

between data controllers and data processors. These

agreements state how some data should be handled by

the data processor.

Since our editor is aimed at professional users, we

use the term user in this paper when talking about pol-

icy authors, who can for example be data controllers

or data protection ofﬁcers. In this paper we address

the following two research questions:

RQ1. How can we improve the GDPR-compliance of

data controllers and their privacy policies?

Leicht, J. and Heisel, M.

Extending PriPoCoG: A Privacy Policy Editor for GDPR-Compliant Privacy Policies.

DOI: 10.5220/0012599600003687

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 19th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2024), pages 307-318

ISBN: 978-989-758-696-5; ISSN: 2184-4895

307

RQ2. How can we improve the usability of the

PriPoCoG-framework?

The paper is structured as follows: First, we intro-

duce some background knowledge in Section 2. Next,

we present our privacy policy editor in Section 3. Af-

terwards, we discuss the evaluation of our editor in

Section 4, followed by related work in Section 5. Fi-

nally, we conclude this paper in Section 6.

2 BACKGROUND

In this section we present some background knowl-

edge about the GDPR terminology, the PriPoCoG-

framework, and P-LPL policies.

2.1 GDPR Terminology

The General Data Protection Regulation (GDPR)

(European Parliament and Council of the European

Union, 2016) introduces some terminology, which we

use throughout the paper to distinguish different roles

that beneﬁt from our policy editor.

Data Subject. Person whose data are collected and

processed by the data controller.

Data Controller. Person or legal entity in charge of

controlling data handling. The data controller

speciﬁes the privacy policy to inform its data sub-

jects.

Data Protection Ofﬁcer. Person, entitled by the data

controller, who ensures GDPR-compliant data

handling. Also handles requests from data sub-

jects.

Data Processor (Data Recipient). External entity

that processes some data on behalf of the data

controller. Called data recipient in the P-LPL

privacy policies.

Purpose. Reason for which data are processed. Pri-

vacy policies contain purposes explaining to the

data subjects why their data are being handled.

Supervisory Authority. The local data protection

authority entrusted with the investigation of data

breaches and with imposing and collecting ﬁnes

for such breaches.

2.2 P-LPL-Policies

The Prolog-Layered Privacy Language (P-LPL) im-

plements and extends the Layered Privacy Language

(LPL) by Gerl (Gerl, 2020). P-LPL uses Prolog

https://www.swi-prolog.org/

to formalize the language constructs of LPL and re-

quirements from the GDPR, as described in (Leicht

et al., 2022). This formalization of the policies as well

as GDPR requirements makes it possible to perform

compliance checks on privacy policies expressed in

P-LPL.

Figure 1 visualizes the structure of P-LPL poli-

cies. The structure shown only contains elements that

are directly created using our editor. P-LPL contains

some elements that are created automatically further

down the data usage chain, for example when the data

subject provides consent to parts of the policy; these

elements are not shown in Figure 1. Square brackets

[] visualize the fact that this element is a set/list of

elements.

Privacy models are used for de-identiﬁcation and

can for example be k-anonymity or l-diversity. They

describe which data are considered during the de-

identiﬁcation process. Automated decision making is

a description of the automated decision making that

might take place for a given purpose. Pseudonymiza-

tion methods explain which data elements are re-

placed by a pseudonym. The purposes of a policy

are organized in a hierarchy to provide different levels

of detail. How the purposes are arranged is saved in

the purpose hierarchy. Policies can have an underly-

ing policy, which can for example be a service level

agreement or a previously accepted privacy policy.

policy

version

name

language

URL (of textual policy)

controllers[]

data protection officers[]

data subject rights[]

supervisory authority

purposes[]

data[]

data recipients[]

retention

legal bases[]

...

purpose hierarchy

underlying policy

Figure 1: Structure of a P-LPL privacy policy, limited to el-

ements created with our editor (some elements are excluded

“. . . ”).

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

308

Threat

Modeler

implements

formalizes

Legislation

(GDPR)

Data

Protection

Authority

Data

Processor

Policy Enforcement

(P2BAC)

PriPoCoG - framework

Management

Policy Authors

Data

Protection

Officer

Data

Controller

Layered

Privacy

Language

P-LPL

(Prolog)

Data Subject

Interface

GUI

general purpose

DFD - Editor

GUI

Figure 2: Uml composite structure diagram of the PriPoCoG-framework with the policy editor highlighted in grey, based on

(Leicht et al., 2023).

2.3 PriPoCoG-Framework

The Privacy Policy Compliance Guidance

(PriPoCoG) framework (Leicht et al., 2022) uses

computer-interpretable privacy policies and checks

them for compliance with the GDPR. We extend this

framework with a privacy policy editor, improving

the usability of the framework. Figure 2 shows an

overview of PriPoCoG, with our editor highlighted in

grey. How our editor integrates into the framework is

described in Section 3.1 below.

The PriPoCoG framework uses P-LPL to imple-

ment LPL and formalize parts of the GDPR. This

formalism is then used to check privacy policies for

compliance with legislation (Leicht et al., 2022), ei-

ther using our policy editor or by directly interact-

ing with the P-LPL command line interface. P-LPL

and consequently our editor can be used by data pro-

tection authorities to investigate GDPR-compliance.

PriPoCoG already provides an editor for data-ﬂow di-

agrams (DFDs), which generates ﬁles that can be im-

ported into our policy editor. The DFD-editor can

be used by policy authors as well as threat model-

ers. The framework also provides policy enforcement

using Privacy Policy Based Access Control (P2BAC)

(Leicht and Heisel, 2023). This enforcement is used

by data controllers and data processors. Privacy pol-

icy management and the privacy policy interface to-

wards the data subject are currently under develop-

ment.

3 EDITOR

In this section we discuss where our editor is situ-

ated within the PriPoCoG-framework. We explain the

functionality of the editor, give some details about the

implementation, and provide a usage procedure. The

editor is open-source and available online

3.1 Framework

Figure 2 shows an overview of where the privacy pol-

icy editor is located within the PriPoCoG-framework.

The contribution of this paper is highlighted in grey.

An overview of the other components of the frame-

work is presented in Section 2.3. In addition to cre-

ating privacy policies, the editor we propose can be

used by policy authors and data processors to deﬁne

service level agreements. Data protection authorities

can use the editor to check the GDPR-compliance of a

given P-LPL policy. Our editor can also be integrated

into future privacy policy management systems.

Figure 3 gives an overview of the different use

cases of our editor. The hierarchy on the left-hand

side of the diagram shows that we deﬁne the actor

Service Provider as a more general term for Data

Controller and Data Protection Ofﬁcer. The Service

Provider has three use cases: i) the general deﬁni-

tion of privacy policies, ii) GDPR-compliance checks

for the policies deﬁned with the editor, and iii) def-

inition of Service Level Agreements (SLAs) in co-

operation/conjunction with Data Processors. Com-

pliance checks can also be used by Data Protection

Authorities, to assure that privacy policies are GDPR-

compliant. The Data Subject can indirectly beneﬁt

from our editor, as the privacy policies are created and

stored in a well-structured manner. This may improve

policy comprehension when combined with a suitable

UI-representation towards the Data Subject.

redacted for blind-review

Extending PriPoCoG: A Privacy Policy Editor for GDPR-Compliant Privacy Policies

309

P-LPL Editor

Service

Provider

Data

Subject

Data

Processor

Data

Protection

Authority

Policy Comprehension

use cases P-LPL Editor

SLA Creation

Compliance Check

Service Provider

Data Controller

Data Protection Officer

«extend»

Figure 3: Use cases for our privacy policy editor.

In the following we take a look at the main fea-

tures of the editor.

3.2 Functionality

We ﬁrst present the basic features that any privacy

policy editor should fulﬁll, before discussing the

unique features of our editor. Figure 5 shows the main

view of the graphical user interface (GUI) of our edi-

tor.

3.2.1 Basic Features

The editor allows users to create and edit privacy poli-

cies. The deﬁnition of a privacy policy is performed

in the two main tabs of the editor, highlighted in the

b-region in Figure 5. The Main Information-tab is

used to specify general information required by a pri-

vacy policy. Here we also specify the basic informa-

tion about the purposes for which data are collected

and processed. Further details about the purposes are

later entered in the Purpose Details-tab.

The privacy policies contain all elements deﬁned

in P-LPL, and the editor provides a structured way of

entering necessary information. Information can be

entered by selecting the corresponding tile in the main

area of the editor (c-region in Figure 5). A form for

entering the relevant information will be shown when

editing policy elements. Figure 6 shows an exemplary

form, ﬁlled with information from the Amazon.de pri-

vacy policy.

The editor provides hints for each ﬁeld, also al-

lowing inexperienced users to deﬁne privacy policies.

Missing or incorrect information is highlighted in red.

Exporting Privacy Policies. The policy created

with the editor can be saved as an XML-ﬁle, and

loaded back into the editor. For a manual GDPR-

compliance check using P-LPL, the policy can also

be downloaded as a Prolog-ﬁle. Additionally, the ed-

itor allows the export of the privacy policy in a plain

text-ﬁle. These operations are available via the main

menu on the left-hand side of the editor (a-region in

Figure 5).

In the following we discuss the unique features of

the editor in more detail.

3.2.2 Unique Features

To the best of our knowledge, the following features

are unique in the context of privacy policy editors and

generators.

GDPR-Compliance. The automatic check of

GDPR-compliance can be divided into two types of

checks:

1. PLP-Checks. The ﬁrst type of check is the

GDPR-compliance check, achieved by integrating P-

LPL into the editor. The information entered in the

editor is transformed to P-LPL syntax and input into

the P-LPL compliance checker. The results of the

compliance check are displayed to the user of the ed-

itor (cf. Figure 4). By integrating P-LPL into the

editor any future updates of P-LPL where the policy

Figure 4: Exemplary compliance feedback: “a dedicated

Data Protection Ofﬁcer (DPO) may be required”, . . . .

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

310

language itself remains unchanged will be directly in-

cluded in our editor. Hence, updates to the compli-

ance checks are easy. Changes to the P-LPL policy

language, however, may require changes in the editor.

Our editor provides an increased usability com-

pared to the bare P-LPL implementation, since the

user does not need to understand Prolog. Addition-

ally, no interaction with a command line interface is

required. Users can just use the editor to deﬁne a pri-

vacy policy and get compliance feedback directly in

the editor.

2. Completeness Checks. In addition to the

compliance-checks performed by P-LPL, the editor

warns the user when some information is missing or

incomplete. This is not strictly a unique feature, but

it is closely related to the compliance checks, hence

we mention it here. Required ﬁelds are marked with

an asterisk * and highlighted in red, when incomplete.

A yellow triangle with an exclamation mark (next to

the SAVE Policy-button in the main menu, a-region

in Figure 5) warns the user before saving an incom-

plete policy. Red exclamation marks on the tiles in

the main-area of the editor further highlight missing

information. Red triangles with exclamation marks in

the tabs (b-region in Figure 5) highlight in which tab

information is missing.

The exclamation marks for missing information,

as well as the question marks for helpful hints, pro-

vide a guided way of deﬁning a privacy policy. We

provide a more detailed description of the guided pro-

cess in Section 3.5 below. There is no ﬁxed order in

which information must be entered, the users can en-

ter the information in any order they like. The com-

pleteness checks ensure that the policy author enters

all information required for a privacy policy.

No Expert Knowledge Required. The structured

nature of P-LPL policies improves the usability of our

editor compared to existing privacy policy editors and

generators. There is no wall-of-text to be edited and

managed. In combination with the guided process the

number of domain experts required during the policy

deﬁnition process is reduced to a single software en-

gineer with knowledge about the system at hand. No

legal expert is required during policy deﬁnition. Only

after ﬁnishing the policy, a legal expert should check

the quality of the policy and make adjustments where

needed.

Importing Information from Software Engineer-

ing Artifacts. Compared to other privacy policy ed-

itors, our editor does not require the user to enter all

information from scratch. Instead, the editor allows

the user to import information about data processing

from data-ﬂow diagrams, as shown in (Leicht et al.,

2023). This makes the policy deﬁnition process less

tedious and reduces the risk of discrepancies between

the policy and actual system behavior.

Structured Policy Representation. The structured

nature of the policies also improves clarity, when a

suitable user interface is used for presentation of the

policy towards the data subject. This enhanced clarity

can further improve the transparency of privacy poli-

cies, resulting in a more informed consent collection,

compared to regular textual privacy policies.

As long as such structured representations of pri-

vacy policies are not standardized by the European

Union, we also support policy authors in legal com-

pliance by providing an export to textual policies.

3.2.3 Extensibility and Adaptability

In its current form, our editor is optimized for GDPR-

compliant privacy policies. However, since the

compliance-checks are separate from the user inter-

face, the editor can be easily adapted to other legisla-

tions.

On the one hand, the compliance-checks can be

replaced with ones of other legislations, e.g., COPPA

(Federal Trade Commission, 1998) or HIPAA (Em-

ployee Beneﬁts Security Administration, 2004). On

the other hand, the editor itself could easily be

adapted/extended to accommodate additional infor-

mation. This may require to adapt the policy language

(P-LPL) and the corresponding model of the policies,

used by the editor.

A possible extension of the editor could be check-

ing the compliance with company-internal policies.

A company or business may have already deﬁned

policies that describe how data may be handled in-

house. Such policies may be conﬂicting with the

data processing stated in the privacy policy. Check-

ing the compliance of a newly deﬁned privacy policy

with such company-internal policies may highlight

misleading information. The misleading information

could then be removed from the privacy policy, in-

creasing transparency and correctness of the policy.

Internal policies to be checked could for example be

business processes, security/access control policies,

or codes of conduct.

The import of policy relevant information from

different sources can also be extended. Currently

information can be retrieved from data-ﬂow dia-

grams. For the future we plan to import information

from business process models in the business process

Extending PriPoCoG: A Privacy Policy Editor for GDPR-Compliant Privacy Policies

311

Figure 5: GUI of our privacy policy editor with the three main regions: a) the main menu, b) main information and purpose

tabs, and c) the main editor area (excerpt).

model and notation (BPMN

), see Section 6.2.

3.3 Development Challenges

In the development of our editor we faced some chal-

lenges, which we brieﬂy discuss in the following.

The integration of the P-LPL compliance checker

was a complicated task as P-LPL is implemented in

Prolog. Available integration layers, which allow

other programming languages to access Prolog, re-

quired us to adapt the usage of P-LPL.

Another challenge was the user interface (UI) de-

sign and the abstraction from the P-LPL language.

The ﬁrst version of the editor provided input ﬁelds for

all information that could be stored in a P-LPL pol-

icy. This, however, made the UI cumbersome to use

and required the user to enter some information re-

peatedly. In the next revision of the UI we abstracted

from P-LPL and only ask the user for input regard-

ing important policy information and generate many

P-LPL ﬁelds automatically from information already

entered by the user.

The export of textual privacy policies was inspired

by the work of Mohammadi et al. (Mohammadi et al.,

2020). Here the challenge lies in the creation of well

structured and ﬁtting patterns, to be instantiated using

the P-LPL policy from our editor.

3.4 Implementation

Our editor is implemented as a web-based tool, which

can also be deployed locally as a stand-alone applica-

https://www.omg.org/spec/BPMN/ (accessed 2023-

12-12)

tion. We use Angular

for the front-end and Python,

which invokes the P-LPL Prolog calls, for the back-

end.

The editor implements the P-LPL privacy policy

model in an object-oriented manner. This ensures

compatibility between our editor and the existing P-

LPL framework.

The editor has a main-menu (a-region in Figure 5)

on the left-hand side of the GUI. This menu contains

actions that can be performed on the whole privacy

policy, e.g., import and export of policies, as well as

the P-LPL compliance check, and a reset-button for

starting over. The save-button downloads the policy

as an XML-ﬁle, whereas the download buttons export

the policy as Prolog-ﬁle or a textual policy. The tex-

tual privacy policy is generated using textual patterns.

The right-hand side of the GUI contains the main edit-

ing tiles (c-region in Figure 5), clustering informa-

tion according to the structure of P-LPL policies. We

make use of tabs (b-region in Figure 5) to divide the

contents of a privacy policy into two types of informa-

tion. In the Main Information-tab we ask the user for

general information about the policy itself, data con-

trollers, data protection ofﬁcers, data subject rights,

supervisory authorities, the data collected, possible

data recipients, the purposes for which data will be

collected and processed, as well as the purpose hier-

archy, structuring the purposes. The main editor-area

is divided into tiles structuring the content of the pri-

vacy policy. Using tiles provides a way of getting an

overview of the policy, before each information cate-

gory can be opened in a separate dialogue.

We use a similar tiled overview in the Purpose De-

tails-tab. Here we ask for further details regarding

https://angular.io/ (accessed 2023-12-04)

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

312

each of the purposes previously deﬁned in the main

information tab. The user should state which data are

going to be collected and processed for a given pur-

pose, recipients of the data, the retention period of the

data collected for a given purpose, and the legal ba-

sis on which the purpose is based. Additionally, the

user can supply privacy models, information regard-

ing automated decision-making, and pseudonymiza-

tion methods used on the data of this purpose.

Each tile of the editor can be used to open a spe-

ciﬁc input form. At the top of these input forms

the main information required by this category is re-

quested. Figure 6 shows the input form for the Es-

sential Information category, ﬁlled with information

from the Amazon.de privacy policy. In this example:

the language of the policy, a name for the policy, and

optionally a URL pointing to the textual representa-

tion of the privacy policy can be entered. Required

ﬁelds are highlighted with an asterisk (*) and colored

red when no information is entered (e.g., Policy name

in Figure 6). Below the main information many pol-

icy elements provide input ﬁelds for a title and a de-

scription. This information can be provided in diverse

Figure 6: Input form for the essential privacy policy infor-

mation.

languages and will be used by privacy policy inter-

faces, when presenting the privacy policy to the data

subject. Since no P-LPL data subject user interface

has been developed yet, this information is consid-

ered optional. However, it is considered good prac-

tice to ﬁll out the titles and descriptions, so that the

information can easily be used by user interface de-

veloped at a later time. The descriptions can be used

to provide reasoning for different elements, for exam-

ple why some data need to be collected or processed.

The use of icons and colors further improves us-

ability of our editor, as the user can get a quick un-

derstanding of missing/wrong information. Advanced

users may also navigate the policy quicker when fo-

cusing on icons instead of reading lengthy titles.

3.5 Usage

As already mentioned earlier, there is no ﬁxed step-

by-step method of deﬁning a privacy policy using our

editor. Policy authors are free to enter information in

any order they may prefer.

The general procedure of deﬁning a privacy policy

in our editor is as follows:

1. Optionally, import information from data-ﬂow di-

agrams, created using the DFD-editor presented

in (Leicht et al., 2023).

2. Enter some information in the Main Information-

tab until all required elements have been ﬁlled.

Alternatively, you can proceed with step three in-

termittently, once you have deﬁned at least one

purpose. You can return to this step at any time.

3. Switch to the Purpose Details-tab to enter infor-

mation about the purposes for which data are col-

lected and processed. If you haven’t completed

step two, yet, you can return to step two intermit-

tently.

4. When all required policy elements are ﬁlled,

check the GDPR-compliance of the policy by

clicking the Compliance Check-button in the main

menu.

5. If something is marked as non-compliant, go back

to editing this policy element and return to Step 3.

6. Finally, if required, export the policy as a textual

This process gives guidance to the user while at the

same time allowing greatest possible ﬂexibility. Next,

we take a look at the evaluation of our privacy policy

editor.

Extending PriPoCoG: A Privacy Policy Editor for GDPR-Compliant Privacy Policies

313

4 EVALUATION

To evaluate our privacy policy editor, we applied a

two-phase approach. In the ﬁrst phase, we asked com-

puter science students for feedback using the ques-

tionnaire described in the next section. Afterwards,

we improved our editor by adding features and chang-

ing the layout of some of its components. In the

second phase, we asked ﬁve computer science re-

searchers to evaluate our editor according to the same

questionnaire. After we analyzed the results of the

second phase, we performed some further improve-

ments, resulting in the privacy policy editor we pre-

sented above. Some of the feedback received in phase

two will be addressed in future updates of the editor.

We used the Technology Acceptance Model

(TAM) by Davis (Davis, 1985) for the evaluation of

our privacy policy editor. Using an adapted TAM-

questionnaire we evaluated the ﬁrst three of the fol-

lowing hypotheses:

H1 The privacy policy editor is easy to use.

H2 The privacy policies created with the editor

have a high quality.

(H2.1) The resulting policies are well structured.

(H2.2) The resulting policies are easy to compre-

hend.

H3 The editor is useful for the creation of GDPR-

compliant privacy policies.

(H4) Privacy policies created with our editor have an

improved accuracy compared to state-of-the-art

textual privacy policies.

(H5) Using our privacy policy editor improves the

transparency conveyed by the privacy policies.

Although we consider hypotheses (H2.1) and

(H2.2) subordinate to H2, they cannot be evaluated

using the TAM questionnaire. The quality of the out-

put of the editor is analyzed in the TAM question-

naire, but not in enough detail to support nor reject hy-

potheses (H2.1) and (H2.2). These hypotheses need

to be evaluated separately, preferably by domain ex-

perts, using a different evaluation methodology.

Hypotheses (H2.1), (H2.2.), (H4), and (H5) will

be evaluated in future work. In this paper we focus on

the privacy policy editor itself.

4.1 Questionnaire

The questionnaire we created for the evaluation of

our editor is a combination of the TAM3 question-

naire from the original TAM by Davis (Davis, 1985)

and the updated questions as described in the later re-

vision of the TAM (Davis, 1989). As suggested by

Davis we adapt the questionnaire by leaving out some

categories of questions as well as adapting individual

questions to our privacy policy editor.

Our questionnaire contains the following four cat-

egories of questions: Overall Evaluation, Perceived

Characteristics of Output, Perceived Ease of Use, and

Perceived Usefulness. Each category includes at least

two questions.

The original TAM contains two more categories.

However, since we evaluated our editor with students

and computer science researchers, which both are

probably not going to work with the editor in their

jobs, we removed the category Anticipated Use from

our questionnaire. And, since the editor is considered

a professional tool, we also excluded the category An-

ticipated Enjoyment of Use.

The original TAM questionnaires used seven-

value scales, e.g., from extremely likely to extremely

unlikely including the neutral option neither. To re-

duce the chance of participants answering neutral for

all questions, we reduced the number of available op-

tions from seven to six, removing the neutral option

neither.

Depending on the question asked, we used one of

the following scales:

• bad → good

• unlikely → likely

• harmful → beneﬁcial

• foolish → wise

• unconﬁdent → conﬁdent

• low → high

• negative → positive

Each of the scales takes the levels of: extremely A -

quite A - slightly A - slightly B - quite B - extremely

B, where A and B are the values of the scales listed

above.

We asked the participants 28 questions overall. 22

of these were adapted from the TAM and four ques-

tions were of demographic nature, including age, gen-

der, and ﬁeld of study. Additionally, we asked for in-

formation regarding prior professional experience in

the ﬁeld of computer science as well as privacy. We

also provided free-text inputs for the participants to

give feedback regarding bugs they might encounter

during the usage of the editor, as well as comments

and general feedback for the improvement of the ed-

itor. A complete overview of the questionnaire is at-

tached in the appendix of this paper.

In the following we take a look at the circum-

stances and results of each of the evaluation phases.

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

314

4.2 Phase 1

In the ﬁrst phase of our evaluation we asked nine

computer science students to participate in our sur-

vey. The participants have at least a bachelor’s degree

in computer science. None of the participants stated

any prior experience in the ﬁeld of privacy. However,

they received a lecture of one hour on privacy and the

GDPR prior to participating in our evaluation survey.

Demographics. The participants were between 20

and 28 years old, resulting in an average age of around

24 years. The group of participants consists of six

male and two female Master students. One person

did not answer the question regarding their gender.

TAM Results (Average).

• Overall Evaluation: slightly positive

• Perceived Characteristics of Output (quality):

quite high

• Perceived Ease of Use: slightly likely

• Perceived Usefulness: slightly likely

The participants rated the editor slightly positive

(4.47/6) in the overall evaluation. The quality of the

resulting privacy policies was considered quite high

(4.83/6). A main concern of the ﬁrst evaluation phase

was usability, as the participants rated ease of use with

slightly likely (4.11/6). The value slightly likely stems

from the way questions are formulated in the TAM

(cf. questionnaire in the appendix).

Bug Reports. The ﬁrst phase identiﬁed some major

bugs, like data loss when accidentally refreshing the

page, as well as some performance issues when edit-

ing long lists of policy elements. We ﬁxed all bugs

that were identiﬁed, before starting the second evalu-

ation phase.

Feature Requests and General Feedback. The

main concern in the general feedback section has to

do with automating more of the input. Some infor-

mation had to be entered manually although it could

be deduced from other inputs. We implemented some

automation for these inputs, to reduce the amount of

manual input by the policy author.

In the ﬁrst phase, the help/descriptions were lack-

ing in information, hence the participants wanted

more information contained in the help texts. Main

information tiles and purposes were listed on a single

page, and participants wanted a better overview. This

is the reason for having two tabs, separating main in-

formation from purpose details.

We also considered further minor feature requests

and feedback for the development of the editor.

We concluded this phase of the evaluation with an

overall slightly positive result. Taking into consider-

ation a list of feedback comments and bug reports,

we improved the editor before conducting the second

phase of the evaluation of our editor.

4.3 Phase 2

In the second phase we interviewed ﬁve computer sci-

ence researchers on an improved version of the editor.

Two of the researchers were Master students, one had

a master’s degree in applied computer science, and

two researchers had PhDs in computer science. Four

male and one female researcher participated in this

phase.

This time we focused on the free-text feedback of

the participants instead of strictly requiring them to

ﬁll out our survey questionnaire. From the four ques-

tionnaires returned we calculated the following eval-

uation results:

TAM Results (Average).

• Overall Evaluation: quite positive

• Perceived Characteristics of Output (quality):

quite high

• Perceived Ease of Use: slightly likely

• Perceived Usefulness: slightly likely

The overall evaluation was more positive in the

second phase. However, the ease of use still was a

major concern with 3.57 out of 6 points. This is also

reﬂected in the feature requests for improved usabil-

ity, which we present below.

Bug Reports. The participants of the second phase

also identiﬁed some bugs in the editor, e.g., crashes

of the back-end. We ﬁxed all bugs and considered a

number of feature requests and general feedback, as

we describe below, for the version of the editor we

present in this paper.

Feature Requests and General Feedback. The

P-LPL required ﬁeld title (HEAD) and description

(DESC) are tedious to ﬁll out for every element

of a privacy policy. Users of the editor do not

see/know the use of this information. We plan to semi-

automatically generate this information, for improved

usability. Some input is repeated throughout the pri-

vacy policy, for example, information regarding enti-

ties that ﬁll in different positions at the same time. A

single person could be considered data controller and

Extending PriPoCoG: A Privacy Policy Editor for GDPR-Compliant Privacy Policies

315

data protection ofﬁcer at the same time. Making such

information reusable is our goal for future updates

of the editor. We provide guidance using help-pages

for each policy element that the policy author needs

to provide. The participants wanted additional infor-

mation directly inside the forms, e.g., by providing

mouse-over texts or additional information next to the

forms. This idea is also planned for a future update of

the editor. Finally, the form controls save and cancel,

currently positioned at the bottom of each form, could

be optimized by also providing them at the top of the

forms. When editing long lists of elements, scrolling

down to the bottom of the page slows down the user

of the editor.

4.4 Evaluation Conclusion

We now summarize the results of our evaluation of

our privacy policy editor by taking another look at the

hypotheses stated in Section 4.

Hypothesis H1 regarding the usability of our ed-

itor can be evaluated using the questions of the cate-

gory Perceived Ease of Use. The results of the surveys

show that the participants have a neutral to slightly

positive opinion on the usability of our editor. This

neither supports nor rejects H1.

Our survey only considers the main hypothesis

H2 in its questionnaire, (H2.1) and (H2.2) need to

be considered in future work. The quality of the

privacy policies is evaluated using the category Per-

ceived Characteristics of Output. The surveys show

that the perceived quality of the resulting privacy poli-

cies is quite high, supporting H2.

Hypothesis H3 can be evaluated using the ques-

tions of the category Perceived Usefulness. Regarding

the usefulness of our editor, we received weak results

tending towards the positive side of the scale. This

neither supports nor rejects H3.

Overall, we can conclude the evaluation with a

slightly positive result. The results of the surveys tend

towards the positive side of the scales for each of the

three hypotheses evaluated in this paper. However,

only one of the hypotheses is signiﬁcantly supported

by the survey results (H2). The other two hypotheses

are only supported slightly, hence we consider these

hypotheses as neutral and propose further evaluation

in the future. A next level of evaluation should in-

clude domain experts, to ﬁnd out whether the editor

is useful in its intended environment and use-case, as

well as to ﬁnd out whether (H2.1) and (H2.2) are sup-

ported.

Hypotheses (H2.1), (H2.2), (H4), and (H5) are

concerned with the characteristics of the privacy poli-

cies that are created with our editor. The characteris-

tics of the policies need to be evaluated in a separate

study. This study should also consider state-of-the-art

textual privacy policies in comparison to P-LPL pri-

vacy policies.

5 RELATED WORK

There exist many different online privacy policy gen-

erators that generate privacy policies according to

some user input. Termly Inc.’s generator

is an ex-

ample of a free privacy policy generator. The user is

interviewed using a comprehensive questionnaire and

the information entered is used to generate a complex

textual privacy policy. The Termly generator has the

beneﬁt of covering a broad range of data protection

legislations. However, it only gives hints concerning

necessary information. The user can skip entering re-

quired information, resulting in a non-compliant pri-

vacy policy. This sort of policy generators is also very

limited in the export of the policy. Most online gen-

erators provide the resulting policy in a textual form,

meaning that other representations of the policies are

not possible without considerable manual effort. Our

editor saves the policy using P-LPL, making it pos-

sible to visualize the policy in many different ways,

which may be developed in the future.

For other kinds of policies, for example access

control policies, commercial products including pol-

icy editors are available. An example of such an ac-

cess control system is the WSO2 Identity Server

which also includes an eXtensible Access Control

Markup Language XACML editor. Due to the lim-

ited access to these commercial systems, we cannot

compare these to our editor.

Gerl and Meier developed a policy editor for the

original Layered Privacy Language (LPL) in conjunc-

tion with extending LPL (Gerl and Meier, 2019).

Their editor is limited to LPL and, thus, cannot be

combined with P-LPL for compliance checks. Hence,

their editor can only check for required ﬁelds or for

ill-formed input like letters in phone numbers or in-

complete e-mail addresses. Compliance checks, as

they are performed by P-LPL in our editor, are not

part of Gerl and Meier’s work.

Dittmann et al. proposed a privacy compli-

ance architecture that ensures the compliance of data

transfers with applicable legislation (Dittmann et al.,

2022). This architecture checks which legislation is

applicable for a given data-ﬂow and ensures that the

data-ﬂow is performed in compliance with the said

https://termly.io/ (accessed 2023-12-07)

https://wso2.com/identity-server/(accessed 2023-12-

13)

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

316

legislation. The presented architecture was developed

in the context of connected-vehicle services, which

however does not limit its use. The architecture could

be adapted to and included in the PriPoCoG frame-

work, as an additional compliance measure for chang-

ing legislative contexts.

6 CONCLUSIONS

We presented our privacy policy editor and now dis-

cuss our contributions and take a look at future work.

6.1 Contributions

Policy authors are supported during the policy deﬁni-

tion process by the GDPR-compliance feedback from

our editor. This enables persons from other domains

than the legal department to specify privacy policies.

Data subjects proﬁt from well-structured and

GDPR-compliant privacy policies. With the improved

comprehension of privacy policies data subjects can

make a more informed decision when accepting or re-

jecting some data processing.

The P-LPL policies deﬁned with our editor can

also be enforced using P2BAC (Leicht and Heisel,

2023), where both sides, data controllers as well as

data subjects beneﬁt from this enforcement.

When policy information is imported from DFDs

the accuracy of the privacy policies is increased.

Hence, there are less discrepancies between the data

handling described in the policy and the actual data

handling performed by the system.

Going back to our research questions presented in

Section 1 we provide the following answers. Con-

cerning RQ1, the GDPR-compliance of data con-

trollers, our editor provides compliance feedback to

the policy authors. This will improve the overall

GDPR-compliance of data controllers by reminding

them that some data processing might not be compli-

ant. Regarding RQ2, the usability of the PriPoCoG-

framework, we provide a user interface for the def-

inition of P-LPL policies, which enables policy au-

thors without prior knowledge of P-LPL in creating

privacy policies. We conclude that our editor provides

answers for both of the research questions.

Next, we take a look at future work around the

editor and the PriPoCoG-framework.

6.2 Future Work

Future updates of the editor could improve usability

and add new features. Similar to the DFD-import

functionality described in Section 3.5, an import func-

tionality for business process models could useful, as

these models contain a lot of information about busi-

ness processes that might be relevant for a business’

To further improve the comprehension of the re-

sulting privacy policies, future work should focus on

the presentation of policies towards data subjects. Us-

ing P-LPL as a policy exchange format, different

kinds of policy interfaces could be developed and

evaluated. A service provider could provide multi-

ple views for its privacy policy, so that data subjects

could select the best view for the best comprehension.

As already mentioned in Section 4, further evalua-

tion of the privacy policies created using our editor is

required in the future. This evaluation should include

the comprehensibility (H2.2), as well as the accuracy

of the policies (H4), compared to commonly used tex-

tual privacy policies.

The PriPoCoG framework and especially P-LPL

could also be extended and adapted to other legisla-

tions.

REFERENCES

Davis, F. D. (1985). A technology acceptance model for

empirically testing new end-user information systems:

Theory and results. Thesis, Massachusetts Institute of

Technology.

Davis, F. D. (1989). Perceived usefulness, perceived ease of

use, and user acceptance of information technology.

MIS quarterly, pages 319–340.

Dittmann, G., Giblin, C., Osborne, M., and Rahul, R.

(2022). Automating privacy compliance in the decen-

tralized enterprise. In 2022 IEEE International Con-

ference on Big Data (Big Data), pages 2218–2223.

IEEE.

Employee Beneﬁts Security Administration (2004). The

Health Insurance Portability and Accountability Act

(HIPAA).

European Parliament and Council of the European Union

(2016). Regulation 2016/679 of the European Par-

liament and of the Council of 27 April 2016 on the

protection of natural persons with regard to the pro-

cessing of personal data and on the free movement of

such data, and repealing Directive 95/46/EC (General

Data Protection Regulation). Ofﬁcial Journal of the

European Union, L119:1–88.

Federal Trade Commission (1998). Children’s Online Pri-

vacy Protection Rule (“COPPA”).

Gerl, A. (2020). Modelling of a privacy language and ef-

ﬁcient policy-based de-identiﬁcation. Thesis, Univer-

sit

at Passau.

Gerl, A. and Meier, B. (2019). The layered privacy lan-

guage art. 12–14 GDPR extension–privacy enhanc-

Extending PriPoCoG: A Privacy Policy Editor for GDPR-Compliant Privacy Policies

317

ing user interfaces. Datenschutz und Datensicherheit-

DuD, 43(12):747–752.

Leicht, J. and Heisel, M. (2023). P2BAC: Privacy pol-

icy based access control using P-LPL. In Mori, P.,

Lenzini, G., and Furnell, S., editors, 9th International

Conference on Information Systems Security and Pri-

vacy, pages 686–697. SciTePress.

Leicht, J., Heisel, M., and Gerl, A. (2022). PriPoCoG:

Guiding policy authors to deﬁne GDPR-compliant

privacy policies. In International Conference on Trust

and Privacy in Digital Business, pages 1–16. Springer.

Leicht, J., Wagner, M., and Heisel, M. (2023). Creating pri-

vacy policies from data-ﬂow diagrams. In Computer

Security. ESORICS 2023 International Workshops.

Mohammadi, N. G., Leicht, J., Goeke, L., and Heisel, M.

(2020). Assisted generation of privacy policies using

textual patterns. In ENASE, pages 347–358.

APPENDIX

The questionnaire contained the following questions.

Although we list them here by TAM category, they

were presented to the participants in a mixed order.

The conﬁdence question was repeated for each page

of the questionnaire (three times), except for the free

text feedback part. Participants were asked to answer

these questions from the perspective of being a Data

Controller, who uses PriPoCoG to deﬁne a GDPR-

compliant privacy policy for their online service. The

answer scales were inverted for some of the questions,

so that participants had to actively think about placing

a cross at the intended position on the scale.

Overall Evaluation.

1. Using PriPoCoG in my job would be . . .

extremely bad → extremely good

2. Using PriPoCoG in my job would be . . .

extremely harmful → extremely beneﬁcial

3. Using PriPoCoG in my job would be . . .

extremely foolish → extremely wise

4. Using PriPoCoG in my job would be . . .

extremely negative → extremely positive

Perceived Characteristics of Output.

5. Assuming I were to use PriPoCoG, the quality of

the privacy policy I would get would be high. —