Approach for defining assessment criteria based on a multidisciplinary analysis.
As shown in the figure above, we propose a refinement process of high-level principles into a set of (instances of) technical requirements based on multidisciplinary analysis, considering the legal, social, business, and technical domain. Each one identifies the objectives and/or risks of identified/perceived from their respective domains and the subsequent high-level requirements for their realization/mitigation. These high-level requirements are then translated into a set of instances of technical requirements that can be used as criteria to assess the fulfillment of a principle.
The refinement process includes the following levels:
- First level: Principles that should be considered to build a trustworthy system (e.g., privacy, security, reliability, safety, and so on). These principles may be derived from different social/cultural demands which, in turn, when sufficiently many stakeholders share such demands, they can be embodied into legal frameworks like GDPR within the European Union. These principles can also be used to analyze and to understand what technical properties (sub-attributes) are required to meet them.
- Second level: Technical sub-attributes derived from principles. Principles are abstract goals, so the sub-attributes define guidelines to fulfill a principle.
- Third level: Types of requirements aim at defining a “common language” to specify, in the fourth level, the necessary (technical) instances of requirements derived from the other realms. These types of requirements allow to take inputs from different sources (e.g., GDPR or ePrivacy from the legal realm) and translate into the necessary instances of requirements. Each type of requirement includes a set of fields and their respective enumeration of possible values, so a common format for instances of requirements can be used.
- Fourth level: (Technical) instances of requirements which, ideally, are the result of convergence among social, legal, and/or business realms. The definition of instances of requirements takes as input (1) the types of requirements identified in the third level that states a common language to define instances, and (2) the high-level principles derived from several sources in other domains (e.g., GDPR or ePrivacy from the legal realm). For example, the GDRP from the legal realm can lead to the definition of technical instances of intervenability requirements. An example is given in the feasibility description.
Instances derived from legal are mandatory (IR1.1, IR1.2, IR1.N); however, a multidisciplinary analysis may lead to identifying, for example, those requirements that influence the individuals’ trust (IR1.2). On the other hand, other instances of requirements (TR1.1) may derive from perceived social expectations or risks that have not yet been considered in the legal realm.
Level 1: Privacy
Level 2: Intervenability
Level 3: Intervenability includes two types of requirements: the first one is intended to the data subject, and the other to the supervisory authority. Each of them has a set of particular fields and their respective enumeration of possible values.
- IR1. - DataSubjectInterventionRequirement is a type of intervenability requirement representing intervention possibilities for data subjects, and;
- IR2. – AuthorityInterventionRequirement is a type of intervenability requirement representing intervention possibilities for supervisory authorities.
In this example, we refer only to the first type of intervenability requirement. The IR1 defines the following fields:
- effect: InterventionEffect [1...*]
- type: DataSubjectIntervention 
- consequence: String 
- time: ActionTime 
The field effect describes the consequences of an intervenability requirement on personal data; for example, access to personal data, personal data is not processed, etc. (all possible values are listed below). The field type describes how a data subject or supervisory authority can cause the required effect. One type can cause several possible effects (e.g., a withdrawConsent can cause a noProcessing and erasure effect). The field time describes when a data subject can exercise the corresponding type intervention. Finally, the field consequence provides a textual description of the consequences that the utilization of a type intervention.
These fields can be set to one of the following values:
- InterventionEffect: access, noProcessing, restrictedProcessing, amendment, correction, erasure, dataCopy, and suspendDataFlows.
- DataSubjectIntervention: doNotConsent, withdrawConsent, review, challengeAccuracy, challengueCompleteness, object, and requestDataCopy.
- ActionTime: beforeCollection, beforeUse, beforeTransmission, onRequest, afterRecognition, atRecording, anyTime.
Based on these fields, one (technical) intervenability requirement may take this form:
- IR1.X : <time> the “dataSubject” shall be able to <type> to the processing described in <processing>. Such intervention should result in <effect> and can have the consequences <consequence> for “dataSubject”.
Level 4: Based on the previous definition, the necessary instances can be defined taking as input the high-level principles from other realms. For example, considering the outcomes of D4.1(legal perspective) by CERAPS, the GDPR promotes that a data subject has given consent to the processing of his/her personal data. According to GDPR, processing has a broad meaning; therefore, it includes collection, flow, storage, and so on.
As stated above, taking as input this (legal) high-level principle and the types of (technical) intervenability requirements, WP4 (legal) and WP5 (technical) partners should perform an analysis to define the instances of intervenability requirements. For example, any “processing requirement” may require the following instances:
- IR1.1: <time> the “dataSubject” shall be able to doNotConsent to the processing described in <any processing req>. Such intervention should result in noProcessing and can have the consequences <consequence> for “dataSubject”.
- IR1.2: anyTime the “dataSubject” shall be able to withdrawConsent to the processing described in <any processing req>. Such intervention should result in erasure and can have the consequences <consequence> for “dataSubject”.
Regarding IR1.1, the time field can take different values depending on the “processing requirement”. For flow requirements, time is set to beforeCollection if the personal data is directly collected from the data subject, and it is set to beforeTransmission if the personal data is derived from other personal data:
- beforeCollection the “dataSubject” shall be able to doNotConsent to the processing described in <collection requirement>. Such intervention should result in noProcessing and can have the consequences <consequence> for “dataSubject”.
- beforeCollection the “dataSubject” shall be able to doNotConsent to the processing described in <flow requirement>. Such intervention should result in noProcessing and can have the consequences <consequence> for “dataSubject”.
- beforeTransmission the “dataSubject” shall be able to doNotConsent to the processing described in <flow requirement>. Such intervention should result in noProcessing and can have the consequences <consequence> for “dataSubject”.
The resulting instances of requirements are context-dependent. On the other hand, these resulting instances can be used as criteria to assess the extent to which GDPR (or other) intervenability is met.
We think that a similar approach can be performed along with WP3 (social perspective) to determine, e.g., which of these instances influence, to a greater or lesser extent, on the individuals’ trust. In this sense, based on the perceived risks and the subsequent high-level requirements regarding the trust on ICT products and services identified by WP3, we can identify those technical instances that shall be considered. Also, we are wondering whether can be answered, for example, these questions? A consent/notConsent intervention and the subsequent noProcessing effect influence the individual’s trust? Or a withdrawConsent intervention and the subsequent erasure effect influence the individual’s trust?
 To illustrate this example, we have used some outcomes from "Understanding the Privacy Goal Intervenability" by Rene Meis. This document can be found in Library Section.
 Intervenability is defined as the property that data subject intervention is possible concerning all ongoing or planned personal data processing (e.g. consent, rectification, erasure, withdraw consent, present a claim, etc.). Even though transparency is mainly intended to data subjects, it could be relevant to other stakeholders, for instance, supervisory authority.