Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

A central concern of end-users with regard to privacy is that they have almost no control over their personal data once these are put into an information system [1–4]. End-users wish for more empowerment, i.e. they want to keep the control over their personal data and how their data is processed by information systems. Hansen [5] summarizes this and other privacy needs into the privacy goal intervenability. Hansen states “Intervenability aims at the possibility for parties involved in any privacy-relevant data processing to interfere with the ongoing or planned data processing. The objective of intervenability is the application of corrective measures and counterbalances where necessary.” [5].

Intervenability is a complex software quality that is strongly coupled with other privacy-related goals. For example, end-users have to be sufficiently aware of how and what personal data is processed and which options exist to intervene in order to be able to exercise these options. Hence, the privacy goal transparency can be seen as prerequisite for intervenability.

As a first step to assist requirements engineers to deal with the complex privacy goal intervenability, we propose a requirements taxonomy that further refines intervenability into subrequirements enriched with attributes and associated to transparency requirements that we identified in [6]. The taxonomy shall help requirements engineers to understand which intervenability and transparency requirements have to be considered for the system they analyze.

The rest of the paper is structured as follows. Our privacy requirements taxonomy is derived and presented in Sect. 2 and validated using related work identified using a systematic literature review in Sect. 3. Section 4 concludes the paper.

2 Deriving and Structuring Requirements on Intervenability

In Sect. 2.1, we systematically analyze the privacy principles described by the international standard ISO/IEC 29100:2011 [7] and the draft of the EU data protection regulation [8] to derive the intervenability requirements they contain and the transparency requirements related to them. To derive the requirements, we analyze the description of the privacy principles and the formulations of the regulation. We keep the formulation of the identified intervenability and transparency requirements close to the original documents from which we identified them. In Sect. 2.1, we enumerate these derived requirements using the notation In for intervenability requirements and Tn for the related transparency requirements. As the ISO principles and EU articles partly overlap, we identified several refinements of identified requirements. We relate those requirements using a refines relation. If an intervenability requirement I\(n_1\) refines a part of another requirement I\(n_2\), this means that I\(n_1\) adds further details on how or which possibilities have to exist to intervene in the processing of personal data. Furthermore, we identified that there are transparency requirements that are closely related to intervenability requirements. This is, because in order to be able to make use of intervenability mechanisms, data subjects have to be aware of them. Hence, we use a relatedTo relation to make the relations between transparency and intervenability requirements explicit. The refines (directed dashed edges) and relatedTo (solid edges) relation are visualized as an initial overview of intervenability requirements in Fig. 1. In Sect. 2.2, we structure the intervenability requirements identified in Sect. 2.1 into a taxonomy of intervenability requirements and integrate this taxonomy into the taxonomy of transparency requirements introduced in [6]. The taxonomy is presented as an extensible metamodel using a UML class diagram.

ISO/IEC 29100:2011 and the draft of the EU data protection regulation do not use the same terminology. To avoid ambiguities, we use the following term definitions from the draft of the EU data protection regulation in this paper.

  • Data subject “means an identified natural person or a natural person who can be identified, directly or indirectly, by means reasonably likely to be used by the controller or by any other natural or legal person, [...].” This term is called PII principal in ISO/IEC 29100:2011.

  • Personal data “means any information relating to a data subject.” This term is called personally identifiable information (PII) in ISO/IEC 29100:2011.

  • Processing “means any operation or set of operations which is performed upon personal data or sets of personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, erasure or destruction.”

  • Controller “means the natural or legal person, public authority, agency or any other body which alone or jointly with others determines the purposes, conditions and means of the processing of personal data; [...].” This term is called PII controller in ISO/IEC 29100:2011.

  • Supervisory authority “means a public authority which is established by a Member State in accordance with Article 46.” Article 46 states that supervisory authorities “are responsible for monitoring the application of this Regulation and for contributing to its consistent application throughout the Union, [...].”

2.1 Requirements Identification from Privacy Principles and Legislation

ISO/IEC 29100 Privacy Principles. To derive our taxonomy of intervenability requirements, we first consider the international standard ISO/IEC 29100:2011 [7], which defines 11 privacy principles which are a superset of the OECD principles [9] and the US fair information practices (FIPs) [10].

We start our analysis with the consent and choice principle, which is obviously concerned with providing data subjects the power to decide how their data is processed. From this principle, we obtain the following intervenability and transparency requirements.

  1. I1

    Present to the data subjects the choice whether or not to allow the processing of their personal data.

  2. I2

    Obtain the opt-in consent of the data subject for collecting or otherwise processing sensitive personal data.

  3. T1

    Inform data subjects before obtaining consent about their rights to access their personal data and to influence the processing of these.

  4. I3

    Provide data subjects with the opportunity to choose how their personal data is handled.

  5. I4

    Allow data subjects to withdraw consent easily and free of charge.

  6. T2

    Where the personal data processing is not based on consent but instead on another legal basis, the data subject should be notified wherever possible.

  7. I5

    Where the data subject has the ability to withdraw consent and has chosen to do so, these personal data should be exempted from processing for any purpose not legally mandated.

  8. I6

    Provide data subjects with clear, prominent, easily understandable, accessible and affordable mechanisms to exercise choice and to give consent in relation to the processing of their personal data at the time of collection, first use or as soon as practicable thereafter.

Requirement I3 states that data subjects shall have the opportunity to choose how their data is handled and is the most general intervenability requirement. It is refined by I1 (cf. Fig. 1) that states that data subjects shall have the choice whether their data is processed or not. I1 is further refined by I2 that requires opt-in consent for processing of sensitive personal data, I4 that requires the possibility to withdraw consent, and I6 that describes requirements for the mechanisms to realize I1. I5 refines I4 by describing the effects of withdrawing consent. Both transparency requirements T1 and T2 are related to I1 (cf. Fig. 1). T1 requires that data subjects have to be informed about their rights before consent is obtained. T2 requires to inform data subjects if their data is processed without their explicit consent.

Fig. 1.
figure 1

Initial overview of intervenability requirements

Full size image

From the openness, transparency and notice principle we identify an additional transparency requirement that is related to all intervenability requirements that describe the choices and means for data subjects to influence how their data is processed (cf. Fig. 1).

  1. T3

    Disclose the choices and means offered by the controller to data subjects for the purposes of limiting the processing of, and for accessing, correcting and removing their information.

The following two intervenability requirements are derived from the individual participation and access principle.

  1. I7

    Give data subjects the ability to access and review their personal data, provided their identity is first authenticated with an appropriate level of assurance and such access is not prohibited by applicable law.

  2. I8

    Allow data subjects to challenge the accuracy and completeness of their personal data and have it amended, corrected or removed as appropriate and possible in the specific context.

I7 and I8 are not refinements of the already identified intervenability requirements, because they are not concerned with how data subjects can influence how or if their personal data is processed. But we consider I8 as a kind of refinement of I7, because I8 depends on I7. Note that I7 prescribes that data subjects shall be empowered with the ability to access and review their personal data. Hence, I7 is considered as an intervenability requirement. Nevertheless, allowing data subjects to access and review their personal data also contributes to transparency.

The other principles presented in ISO 29100 do not contain further statements from which we can derive intervenability requirements.

Draft of the EU Data Protection Regulation. To identify further intervenability and transparency requirements and to refine the already identified requirements, we analyze the draft of the EU data protection regulationFootnote 1 [8]. We selected this regulation as a representative data protection regulation. In contrast to the situation in the US where no privacy regulations covering all industrial branches exist, the EU data protection regulation covers all industrial branches.

Article 7 describes the conditions for consent and we derive from it the following intervenability requirement that refines I4.

  1. I9

    The data subject shall have the right to withdraw his or her consent at any time.

Article 12 specifies requirements on mechanisms for exercising the rights of data subjects. We identified the following two transparency requirements that are related to all intervenability requirements that describe the choices and means for data subjects to influence how their data is processed.

  1. T4

    The controller shall inform the data subject without delay and, at the latest within one month of receipt of the request, whether or not any action has been taken if a data subject requested information and shall provide the requested information.

  2. T5

    If the controller refuses to take action on the request of the data subject, the controller shall inform the data subject of the reasons for the refusal and on the possibilities of lodging a complaint to the supervisory authority and seeking a judicial remedy.

Article 17 is about the right to be forgotten and to erasure. From this article we derive the following requirements.

  1. I10

    The data subject shall have the right to obtain from the controller the erasure of personal data relating to them and the abstention from further dissemination of such data if the data subject withdraws consent or objects to the processing of personal data.

  2. I11

    The controller shall carry out the erasure without delay, except to the extent that the retention of the personal data is necessary.

  3. I12

    Where erasure is not possible, the controller shall instead restrict processing of personal data.

  4. T6

    The controller shall inform the data subject before lifting the restriction on processing.

I10, I11, and I12 refine the consequence of withdrawing consent (I4) and objecting to processing (I14 see below). T6 requires that data subjects are informed about the restrictions on processing implied by I12 before these are lifted.

The right to data portability is introduced by Article 18. It implies the following intervenability requirement that refines I7.

  1. I13

    The data subject shall have the right, where personal data are processed by electronic means and in a structured and commonly used format, to obtain from the controller a copy of data undergoing processing in an electronic and structured format which is commonly used and allows for further use by the data subject.

Article 19 describes the right to object. From this we derived the following two intervenability requirements that refine I3.

  1. I14

    The data subject shall have the right to object, on grounds relating to their particular situation, at any time to the processing of personal data, unless the controller demonstrates compelling legitimate grounds for the processing.

  2. I15

    If the objection is valid, the controller shall no longer use or otherwise process the personal data concerned.

Article 53 describes the powers of supervisory authorities. In contrast to the previously identified requirements, the following requirements do not describe intervention possibilities for data subjects or needs to provide information to data subjects, but for/to supervisory authorities.

  1. T7

    Supervisory authorities may order the controller to provide any information relevant for the performance of their duties to them.

  2. I16

    Supervisory authorities may order the rectification or erasure of all data when they have been processed in breach of the provisions of a regulation.

  3. I17

    Supervisory authorities may impose a temporary or definitive ban on processing.

  4. I18

    Supervisory authorities may order to suspend data flows to a recipient in a third country or to an international organization.

Table 1 summarizes from which ISO 29100 principles and articles of the draft of the EU data protection regulation which initial intervenability and transparency requirements were derived. Additionally, it allows to associate the elements of our intervenability requirements taxonomy (introduced in the next section) with the principles and articles from which these were identified.

Table 1. Mapping of ISO principles and data protection articles to the requirements
Full size table

2.2 Setting up an Intervenability Requirements Taxonomy

We now structure the identified preliminary intervenability requirements into an intervenability requirements taxonomy. We integrate this taxonomy into the transparency requirements taxonomy presented in earlier work [6] using the related preliminary transparency requirements. Figure 2 shows our taxonomy in the form of a metamodel using a UML class diagram. Note that we only show the attributes and enumerations of the transparency taxonomy that are relevant for this paper. All elements that have bold font and thick lines are newly added to the transparency taxonomy. The requirements with dark gray background represent the newly identified transparency and intervenability requirements.

Table 2 provides an overview of how the initial requirements are reflected in our proposed taxonomy. In the following, we explain the new elements of our taxonomy and how they are related to the requirements introduced in [6].

Fig. 2.
figure 2

Our combined taxonomy of transparency and intervenability requirements.

Full size image
Table 2. Mapping between taxonomy and preliminary requirements
Full size table

Intervenability Requirement. The root element of our intervenability requirements taxonomy is the IntervenabilityRequirement. We modeled it as an abstract class because only its specializations shall be instantiated. It contains the attribute effect that describes the consequences of an intervenability requirement. The possible effects are derived from the preliminary requirements I1, I3, I5, I7, I8, I10–I13, and I15–I18, and are summarized in the enumeration InterventionEffect (cf. Fig. 2). The effects are that data subjects get access to their personal data, that their personal data is not processed, that the processing is restricted, that their personal data is amended, corrected, or erased, that they receive a copy of their data, and that data flows are suspended. In addition to the effect that an intervenability requirement shall have, it has a type describing how data subjects or supervisory authorities can cause the wanted effects. As these types differ for data subjects and authorities, we added the attribute type to the intervenability requirements DataSubjectInterventionRequirement (representing intervention possibilities for data subjects) and AuthorityInterventionRequirement (representing intervention possibilities for supervisory authorities).

Table 3. Mapping between authority intervention types and intervention effects
Full size table

AuthorityInterventionRequirement. Almost all initial requirements describe rights of data subjects to influence how their personal data is processed. Only I16, I17, I18, and T7 present possibilities for supervisory authorities to intervene in the processing of personal data. The intervention types for authorities are summarized in the enumeration AuthorityIntervention (cf. Fig. 2). Supervisory authorities may order to suspend data flows, order a ban of processing of personal data, and order the erasure or rectification of personal data. The initial requirements I16, I17, and I18 also describe which type of intervention shall lead to which kind of intervention effect. Hence, there are limitations for the combination of intervention types and effects when an ExceptionalInformationRequirement is instantiated. Table 3 presents the valid combinations of intervention types and effects.

T7 indicates that supervisory authorities have to be informed about the processing in order to exercise their rights to intervention properly. Hence, each AuthorityInterventionRequirement has an ExceptionalInformationRequirement assigned that describes which supervisory authorities may intervene. We newly introduced into the enumeration ExceptionalCase the literals nonCompliance and authorityRequest to reflect that authorities have to be informed in the case of processing of personal data in a way that does not comply with the regulations and that authorities then have the possibility to intervene in this processing. Additionally, authorities have the right to request information concerning the processing of personal data from the controller.

Table 4. Mapping between data subject intervention types and intervention effects
Full size table

DataSubjectInterventionRequirement. The DataSubjectInterventionRequirement presents the possibilities for data subjects to intervene in the processing of their personal data. These possibilities are summarized in the enumeration DataSubjectIntervention (cf. Fig. 2) that we derived from the preliminary requirements I1–I5, I7, I8, and I10–I15. These initial requirements additionally describe which combinations of intervention types and effects are allowed for DataSubjectInterventionRequirements. The valid combinations are shown in Table 4.

T1, T3, I6, and I9 require that data subjects have to be informed about how they can intervene in the processing of their personal data. To reflect this, we introduced the association controlOptions between DataSubjectInterventionRequirement and ProcessingInformationRequirement (cf. Fig. 2). From the perspective of the ProcessingInformationRequirement, the association describes which options exist for data subjects to intervene in the processing of their personal data. The two attributes consequence and time of DataSubjectInterventionRequirement are used to describe further details on the control option described by the DataSubjectInterventionRequirement. The attribute consequences allows to provide a textual description of the consequences that the utilization of the corresponding intervenability option has. The attribute time describes when data subjects can exercise the corresponding option.

From the preliminary requirements T4–T6, we identified that an additional transparency requirement should be added to the taxonomy. This requirement states the need to inform data subjects about the progress or rejection of interventions requested by them. For this purpose, we introduce the InterventionInformationRequirement. Each DataSubjectInterventionRequirement is associated to an InterventionInformationRequirement and vice versa that presents the need to inform data subjects about the progress or rejection of their intervention.

Furthermore, we identified from T2 that the ProcessingInformationRequirement should also inform data subjects about the legal grounds on which their data is processed. For this, we enriched this requirement with an attribute grounds that reflects the possible grounds for processing personal data by the controller. These are derived from ISO 29100 and the draft of the EU data protection regulation. They are consent of the data subject, the vital interest of the data subject, an existing contract, a regulation that allows the processing, and public interest.

3 Validation of the Taxonomy Using Related Literature

In this section, we give an overview of existing research that also contains considerations about the privacy goal of intervenability. To validate our proposed taxonomy, we map the notions and concepts used in the related literature to our taxonomy to check whether it is suitable to reflect the intervenability concepts used in the literature.

To identify the relevant related work, we performed a systematic literature review using backward snowballing [11]. To obtain the starting set of papers for our review, we manually searched the proceedings and issues of the last 10 years of computer science conferences and journals that are mainly concerned with at least one of the topics privacy, requirements, and software engineering and ranked at least as B-level in the CORE2014Footnote 2 ranking. In this way, we selected 15 conferences and 19 journals. First, we checked whether title or abstract of a paper indicates that the paper is concerned with privacy (requirements), intervenability, empowerment, user’s controls, or user’s choices. In this way, we obtained 219 articles. We then analyzed the full texts of these articles. Doing this, we reduced the number of relevant articles to 21. Due to the manual search process, we have to deal with the threat to validity that our starting set of papers does not contain all relevant literature, because it was published in a source that we did not consider or was published earlier than in the last 10 years. To mitigate this threat, we applied backward snowballing. That is, we also considered the papers referenced in the papers that we identified as relevant until no new candidates were found. During the snowballing, we identified 79 possibly relevant articles from which 12 were finally considered as relevant. In total, we identified 298 papers that seemed to be relevant after reading title and abstract. After the analysis of the full text, we finally identified 33 papers as related work. Due to space limitations, we cannot present all details of the literature review in this paper, but we provide an overview of our key findings.

The most important finding is that we are able to map each explicitly mentioned intervenability-related concept in the literature to an element of our taxonomy and that none of the articles provides such a structured overview of intervenability requirements and relates these explicitly to transparency requirements. Table 5 shows to which degree the articles identified during the literature review address the intervenability requirements that we identified in this work. For each article, we investigated to which degree aspects of the DataSubjectInterventionRequirement (column DIR), the AuthorityInterventionRequirement (column AIR), and the relations between intervenability and transparency requirements (column RIT) are mentioned in it. We distinguish in Table 5 three cases. If all aspects are addressed, we denote this with a “+”. If the aspects are only partially considered, then we denote this with a “o”. If no aspects are addressed, we denote this with a “−”.

From Table 5, we can see that no article discusses all aspects concerning the relation between intervenability and transparency requirements. Several papers mention that transparency is a prerequisite for intervenability or that data subjects have to be aware of their options to intervene in the processing of their personal data, but none of the papers mentioned that data subjects have to be informed about the progress of the intervention requests they have triggered. Few of the articles considered the intervention options of supervisory authorities. Only three articles covered all of the aspects and 5 identified the need to be able to answer requests of supervisory authorities in order to prove compliance with regulations or standards. All articles discuss at least partially options for the data subject to intervene into the processing of their personal data. The most often discussed intervenability option is to consent or withdraw consent. Another interesting observation that we made is that only Hoepman [13] discusses the right to data portability. This right, its implementation, and consequences seem to not yet have been discussed deeply in the literature.

Table 5. Mapping of intervenability notions from the literature to our taxonomy
Full size table

4 Conclusions

In this paper, (1) we systematically derived requirements for the privacy goal intervenability and related transparency requirements from the ISO 29100 standard [7] and the draft of the EU data protection regulation [8]. (2) We then integrated these requirements into an existing metamodel for transparency requirements [6]. The new metamodel provides an overview of the identified kinds of transparency and intervenability requirements and how these are related to each other. The metamodel shall furthermore help requirements engineers to identify and document the transparency and intervenability requirements relevant for them and the information needed to address the transparency and intervenability requirements. (3) We performed a systematic literature review and provide an overview of the relevant research related to intervenability requirements. (4) We validated that our taxonomy contains all necessary aspects mentioned in the identified literature. The literature review showed that all aspects of the privacy goal intervenability mentioned in the literature are reflected in the proposed taxonomy. Furthermore, we did not find any literature that presents intervenability requirements and their relation to transparency requirements in such a structured, detailed, and complete manner.

We believe that our taxonomy is flexible enough to also represent intervenability and transparency requirements from other regulations and standards, because our proposed metamodel of the taxonomy can easily be adopted and extended. In these cases our metamodel can be enhanced with, e.g., further intervention types and effects. These can easily be added to the corresponding enumerations (cf. Fig. 2).

For future research, we identified three open research questions. (1) How can the taxonomy be used to derive intervenability requirements for a specific software to be developed? To answer this question, we want to integrate the intervenability requirements and their relations to the transparency requirements into our method for the automatic identification and validation of privacy requirements [44]. (2) Which kinds of threats to transparency and intervenability requirements exist? (3) Which technologies exist that implement transparency and intervenability requirements or mitigate threats to these? To address the latter two questions, we plan to set up a catalog of threats that possibly lead to a violation of the identified transparency and intervenability requirements and related mechanisms that may be used to mitigate the identified threats. Based on this catalog, we want to develop a systematic method to identify the relevant threats for a given set of functional requirements and appropriate countermeasures in order to perform a privacy risk assessment.