Guidelines

Here the goal is to provide a computer expert with some guidelines to instantiate and formalize the concrete application scenario by means of and adopting the proposed methodology. To do this, it is worth to supply some basic legal information and to propose a possible example of legal reasoning aimed to apply the predicates and principles resulting from the analysis to the application scenario.

First of all, we will provide, albeit in a schematic way, the basic concepts. Then, for concreteness we will take as a reference a simple scenario (as described in section 2 of the paper): namely the processing of personal data to produce the salary slips of employees in an Italian organization. Finally, we will highlight the main steps to be taken in order to perform the analysis and the evaluations fit to adopt within the context the principles and terminologies specified in our methodology.

Basic legal information

Given our focus on (purpose-aware) access control policies, we have considered only those provisions directly related to such policies.

Below, we describe the possible types of information that shall be protected, the set of legal roles involved in the processing of data, a set of auxiliary notions that are crucial to express authorization conditions and specify the possible relationships among the various roles or contextual conditions.

Classes of data

From our annotated version of the EU DPD, we have identified the following three classes of data:

  • Personal Data (PD) - shall mean any information relating to an identified or identifiable natural person ('data subject'); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity (art. 2(a));
  • Sensitive Data (SD) - personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, and the processing of data concerning health or sex life (art. 8(1)); and
  • Non-Personal Data (NPD) - information that, either in origin or on account of its having been processed, cannot be associated with any identified or identifiable data subject; hence, the EU DPD may not be applied.

Legal roles

We have defined the following three legal roles:

  • Data Controller (DC) - shall mean the natural or legal person, public authority, agency or any other body which alone or jointly with others determines the purposes and means of the processing of personal data; where the purposes and means of processing are determined by national or Community laws or regulations, the controller or the specific criteria for his nomination may be designated by national or Community law (art. 2(d));
  • Data Processor (DP) - shall mean a natural or legal person, public authority, agency or any other body which processes personal data on behalf of the controller (art. 2(e)); we may eventually have external/outsourced DPs;
  • Data Subject (DS) - shall mean any natural person that is the subject of the personal data (art. 2(a)).

Auxiliary notions

We have singled out the following four recurring conditions for the specification of access control policies to preserve privacy:

  • Purpose - PD shall be collected for specified, lawful and legitimate purposes and not processed in ways that are incompatible with the purposes for which the data have been collected (art. 6(1)(b)). The view adopted in this work is to associate a purpose with a MSC defining a set of plans to achieve certain goals so that an action is carried out in the context of a plan. You may have, within an information system, also a list of sub-purposes.
  • Consent - PD shall be collected and processed only if the data subjects have given their explicit consent to data processing, and if there are no explicit exceptions in this regard (art. 7). This means a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject's agreement to the processing of PD, such as by a written statement, including by electronic means.
  • Consent - PD shall be collected and processed only if the data subjects have given their explicit consent to data processing, and if there are no explicit exceptions in this regard (art. 7). This means a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject's agreement to the processing of PD, such as by a written statement, including by electronic means.
  • Data Quality - PD shall be adequate, relevant, and not excessive with respect to the purposes for which they are collected and processed; accurate and, where necessary, kept up to date; retained no longer than necessary for the purposes for which the data were collected (art. 6(c, d, e)). This requirement ensures that the data processed are always those which are strictly necessary to achieve a certain purpose and represents a variation of the Privacy-by-default principle.
  • Member States Requirements - MSs shall, within the limits of the provisions analised, determine more precisely the conditions under which the processing of personal data is lawful (art. 5). The EU DPD sets the "lowest common denominator" with respect to the legal provisions about data protection and privacy; MSs may indicate additional ones in order to align the EU DPD to their legal systems. This condition allows us to impose additional regulatory constraints when considering scenarios in which national legislations may be more restrictive than the EU DPD. This rule guarantees some flexibility in managing our methodology: it allows the security expert, when formalizing the concrete scenario and within a given national legal system, to better define the environment requirements.

We have also identified two main relationships between DCs and DPs or DSs:

  • Mandate - specifies which operations the DC delegates to the DPs (see art. 2(e), art. 16, art. 17(2,3)). A DP can further delegate some of the operations to other DCs. When the DC mandates an action to a DP, it can still perform the action.
  • Empower - specifies which operations the DC gives the possibility to execute to the DS when interacting with the system being designed. An information system typically provides only a sub-set of all possible operations on some data. The relation 'Empower' allows us to specify which actions the system being designed will support and to which the EU DPD shall apply. The DS should still be able to execute the operations not mentioned in Empower, albeit in ways which are not supported by the system (e.g., by manual intervention of system administrators).

How to apply the methodology to a concrete scenario

To assist the security expert in adopting our tool, we present below a possible (not the only) logical process of (mostly legal) evaluations and decisions to be followed in order to adapt the proposed methodology to the concrete scenario. To do this, as mentioned above, we take as a reference the case of a processing of personal data to produce the salary slips of employees in an Italian organization, named ITOrg. The process is described by the Message Sequence Chart (MSC) of the figure below. ITOrg asks each Employee to fill in a form with profile information such as name, surname, address, number of kids, type of car, etc. The Employee can send the filled in form to ITOrg (message 'profile') and give her consent for some of the purposes for which (parts of) the data in the form can be used. ITOrg delegates the processing of selected parts of the profile to its departments. For producing salary slips, after checking that the employee has given the consent for processing information that are used to compute the salary slips---the callout in the figure, ITOrg forwards the pertinent information in the profile to its Financial Department - message 'fin_profile'. In turn, ITOrg Fin Dept sends (possibly a sub-set of) the received information to ACME (message 'sub_fin_profile') that performs the actual computations to produce the salary slip. Once the computations have been performed, ACME sends the salary slip to ITOrg Fin Dept (message 'salary') that can be furtherly processed (if the case) and finally send the salary slip to the Employee (message 'salary_slip'). Notice that each send and receive event in the MSC is decorated with permissions: r for read, w for write, and u for update. The meaning of such decorations is the following: the entity sending or receiving a message with payload $p$ must have (one of) the permissions in the decoration close to it. For instance, an Employee should be granted the permission to w(rite) or u(pdate) her profile in order to send a message containing it. The fact that an entity has (or not) the permissions specified in the decorations is specified by an access control policy.

1. Purpose

The first activity to be undertaken concerns the identification of the purpose of our scenario. Around this concept revolve a whole series of evaluations, and legal consequences, such as: the type of personal data that can be processed, methods of processing that can be implemented, the data retention time, data quality, etc. In our scenario, ITOrg needs to process personal data of its employees for producing salary slips, after checking that the employee has given the consent for processing information that are used to compute the salary slips. Then, for example, the ITOrg Fin Dept can read the content of a message containing the "salary" of an employee if this action is performed in the process described by the MSC proposed. This implies that we consider access control policies that are purpose-aware. We assign the meaning to a purpose by associating it with a plan to achieve certain goals since "an action is for a purpose if it is part of a plan for achieving that purpose". The use of MSCs allows us also to specify the contextual conditions under which the process (purpose) should be executed, as it is required to specify security policies in almost all modern information systems.

2. Classes of data

The purpose determines what kind of data are needed to address it. Principles such as Privacy by design and, above all, the Privacy by default require that the DC shall implement technical and organizational measures for ensuring that, by default, only personal data which are Necessary for each specific purpose of the processing are processed. Processing PD rather than SD evidently determines also significant differences with regard to the legal regime applicable and to the requirements to be implemented. In our scenario, ITOrg asks each Employee to fill in a form with profile information such as name, surname, address, number of kids, type of car, etc. For producing salary slips (a sub-purpose related to the one indicated above), after checking that the employee has given the consent, for processing information that are used to compute the salary slips, ITOrg forwards the pertinent information in the profile to its Financial Department (i.e. message "fin_profile". In turn, ITOrg Fin Dept sends (possibly a sub-set of) the received information to ACME (message "sub_fin_profile") that performs the actual computations to produce the salary slip. This kind of information are PD, as described above, since they are information relating to an identified.

3. Legal roles

When analising a concrete scenario we have to take into account the possible players involved in and to determine which kind of legal role they may play in it. In our scenario, the DC is ITOrg since it is the legal person which determines the purposes (see above) and means of the processing of PD. The Employee is the DS, since she is an individual that is the subject of the PD held by a DC. The other players, ITOrg Fin Dept and ACME, are, instead, DPs: they are organization that processes PD on behalf of DC.

4. Consent

Given a specified purpose, the consent of the DS legitimates the collection and processing of PD by the DC, if there are no explicit exceptions in this regard. In our scenario, this requirement is considered as a condition that allows the actions needed in the system.

5. Empower and Mandate

Another relevant activities aimed at describing the concrete scenario in the light of the proposed methodology is to precisely identify the relationships between the aforementioned subjects in order to better determine the content and scope of the delegated actions within the information system. While the EU DPD stipulates that---regardless of the purpose---a DS can perform any action on her PD, an information system is usually designed to provide only a sub-set of all possible actions that a DS is entitled to do. For this reason, we introduced "Empower" to express which actions the DS can perform when interacting with the system. Thus, in our scenario, the ITOrg/DC delegates some actions (i.e. read) to the Employee/DS. The same kind of logic needs to be applied with reference to the relationship between DC and DP, by means of the "mandate": in our scenario, the ITOrg/DC delegates some actions with regards to some specific sub-set of data to the ITOrg Fin Dept/DP or to the ACME/DP.

6. MS Requirements

Finally, the predicate MS_Requirements (only if needed in the application context) allows the expert (only if needed in the application context) to insert into the instantiation the additional requirements eventually provided by the national legislator, within the framework and the freedom of action granted by the European one. In our simplified scenario this predicate was not used.

7. Data Quality

As stated above, this predicate ensures that the data processed are those which are strictly necessary to achieve a certain purpose. In our scenario, it represents an environmental requirement that the technical expert has always to take into consideration while checking the privacy compliance of the flows of data involved in the processing.