Editorial Director: Giusella Finocchiaro
Web Content Manager: Giulia Giapponesi

posted by Laura Greco on maggio 15, 2018

GDPR Regulation EU 2016/679, Privacy

Commenti disabilitati

The privacy regulation (Regulation (EU) 2016/679) will be soon directly applicable on the entire European territory. Companies, public administrations and private citizens are in the final rush to comply with the dispositions of the new legislation.

In order to make it easier to understand a complex and articulated text such as the GDPR, we propose hereinafter a collection of simple factsheets, structured with a Q&A formula, that starting from known privacy concepts, give a first and brief guidance to the reading of the new legislation.

What is the Data Protection Impact Assessment?

The new Regulation on data protection (GDPR), obliges controllers to assess the risk to which their processing is likely to expose personal data and consequently the rights and freedoms of natural persons. The Data Protection Impact Assessment, (“DPIA”), is a “continuous process”(an “on-going process) which should be reviewed continuously and whenever there are substantial changes, which ultimately results in a list of activities carried out to assess risk deriving from processing and the means, tools and measures adopted to identify and minimise this risk.

When is it necessary to do a DPIA?

The controller must do a DPIA before beginning any kind of processing, namely in as early as possible a stage of the design of the processing operation where it is still possible to modify and take measures so as to mitigate the likely risk emerging from the assessment. Indeed, this obligation is part of the proactive security approach adopted by the GDPR, consisting of a series of preventive and precautionary tools of protection for the personal data processed.

Is it a mandatory obligation?

DPIAs are only mandatory in certain cases, i.e. in the case of: a) a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person; b) processing on a large scale of special categories of data referred to in Art. 9(1), or of personal data relating to criminal convictions and offences referred to in Art.10; or c) a systematic monitoring of a publicly accessible area on a large scale (see “LINK Faq on DPO” for the concept of “large scale”). It is also provided for that the supervisory authority draws up and publishes a list of the kind of processing operations which are subject to the need for a DPIA.

And even in cases when it is not mandatory, a DPIA is a recommended measure, since it is a useful tool to allow the controller to identify likely situations of risk and to remedy them, before harming data subjects or infringing the law (also to demonstrate compliance with the GDPR).

Who has the obligation of conducting the DPIA?

The controller is responsible for making sure the DPIA is carried out. Another person inside or outside the organisation may carry out the DPIA. However, ultimate accountability for this obligation remains with the controller who should carefully monitor the assessment.

As the GDPR highlights, prior to the processing the controller should consult the Data Protection Officer and the processor. It is also provided for that, where appropriate, the controller (or the subject delegated to do the assessment) should seek the views of data subjects or their representatives about the intended processing. If after having sought the views of data subjects, the controller’s final decision differs from their views, its reasons for going ahead or not should be recorded.

How must a DPIA be carried out?

Whether the DPIA is mandatory or discretionary, it is necessary to perform a systematic description of the processing operations which are likely to result in high risk. For each processing (or category of processing), information will need to be collected on: a) the nature, scope, context and purposes of the processing; b) personal (and sensitive) data, data subjects and period for which the personal data will be stored; c) a functional description of processing operations and, in particular, data flows (i.e., disclosure by transmission, circulation or otherwise making the personal data available, transfer, specifying the recipients whether inside or outside the controller’s organisation); d) the assets on which personal data rely (hardware, software, networks, people, paper or paper transmission channels); e) subjects who might access the data together with the purposes of or reasons for this access.

Subsequently, it will be necessary to assess and describe whether the processing is necessary and proportionate in relation to the purposes and security measures adopted: for each processing, security measures to deal with the risk will need to be checked, including safeguards, security measures and tools to safeguard the protection of personal data.

Thanks to the documentation and information collected, it will be possible to get on with identifying the risks which the personal data are exposed to, analysing their life cycle and taking into account how they are used, the purposes which they are used for, if any new technologies are used and the subjects authorised to process them.

Once the risks have been identified, they will have to be managed. At this stage, it will be necessary to choose (where possible) whether a particular risk should be eliminated, mitigated or accepted.

Where do I keep my DPIA?

Results and observations from the DPIA should merge into a final report, where collected and examined information is presented in a systematic and functional way with measures and remedies adopted and implemented to address risks. The report should specify the name of the organisation or the project for which the DPIA has been carried out, the subjects or the team who have carried out the DPIA and the contact details of a the designated lead contact.

Focus: obligations relating to the DPIA

Even if it is not a legal requirement of the GDPR, in its Guidelines on DPIA adopted on 4th April 2017 and revised on 4th October 2017, Working Party Art. 29 (A29WP) recommends sharing the report (or parts of it – but only non-commercial/sensitive parts) to demonstrate accountability and transparency (and “to help foster trust in the controller’s processing operations”). This is especially encouraged for those organisations where members of the public are affected by the processing operation.

When the risks which have been identified have been successfully managed by the controller with a DPIA, the procedure can be considered concluded. On the contrary, whenever the identified risks cannot be sufficiently addressed by the controller (i.e. when the residual risks are still high), then the controller must consult the supervisory authority, in order to proceed with consultation prior to processing in accordance with Art. 36 of the GDPR.

 

 

posted by Laura Greco on maggio 2, 2018

GDPR Regulation EU 2016/679, Privacy

Commenti disabilitati

The privacy regulation (Regulation (EU) 2016/679) will be soon directly applicable on the entire European territory. Companies, public administrations and private citizens are in the final rush to comply with the dispositions of the new legislation.

In order to make it easier to understand a complex and articulated text such as the GDPR, we propose hereinafter a collection of simple factsheets, structured with a Q&A formula, that starting from known privacy concepts, give a first and brief guidance to the reading of the new legislation.

What is the record of processing activities?

This is a new obligation introduced by the GDPR which requires a full documentation of all processing operations carried out under the authority of the controller and the processor.

Whose obligation is it to keep records?

Novel in the GDPR is that the controller and the processor are both independently responsible for drafting and keeping records. The controller’s record and the processor’s will be two distinct documents, each one with specific content.

Compiling the record could be delegated to the Data Protection Officer (DPO), however, without in this way transferring responsibility for compliance with this obligation from the controller and the processor. The controller and processor could also ask for assistance from department managers in their organisations, who would probably be more familiar with the processing activities carried out in their departments and could more easily provide specific, detailed information about such processing.

Are there any waivers or exceptions in the GDPR?

The new Regulation provides that the duty of maintaining a record of processing activities does not apply to enterprises or organisations employing fewer than 250 persons. However, in order for this exemption to be valid, the processing carried out must not be likely to result in a risk to the rights and freedoms of data subjects, it must be occasional and it must not include special categories of data (e.g. health data, biometric data) or personal data relating to criminal convictions and offences.

What information should be contained in the record?

The minimum content of information changes depending on whether the document concerns the controller’s processing activities or those of the processor.

In the first case, the controller shall indicate: a) the name and contact details of the controller and, where applicable, the joint controller, the controller’s representative and the data protection officer; b) the purposes of the processing; c) a description of the categories of data subjects and of the categories of personal data; d) the categories of recipients to whom the personal data have been or will be disclosed e) where applicable, the identification of the third country or the international organisation to which data are transferred, including the documentation of suitable safeguards; f) where possible, the envisaged time limits for erasure of the different categories of data; g) where possible, a general description of the technical and organisational security measures.

In the second case, the processor shall specify only: a) the name and contact details of the processor or processors and of each controller on behalf of which the processor is acting, and, where applicable, of the controller’s or the processor’s representative, and the data protection officer; b) the categories of processing carried out on behalf of each controller; c) where applicable, the identification of the third country or the international organisation to which data are transferred, including the documentation of suitable safeguards; d) where possible, a general description of the technical and organisational security measures.

Can the record be drafted and kept in electronic form?

The GDPR provides that the records of processing activities must be in writing including in electronic form. Therefore, it will also be possible to draft and keep records directly on IT equipment, for example by creating an Excel file.

Are there other obligations which go with the record?

It is not sufficient to simply draft the processing record in order to be fully compliant with the GDPR. It should be periodically revised and updated, in particular specifying new processing activities and/or removing those which have been terminated, namely the record must be kept up-to-date to reflect an organisation’s present processing activities.

In addition, the controller and the processor (where applicable, their representative) are under the obligation to make the record available to the supervisory authority on request.

 

 

posted by Laura Greco on maggio 15, 2017

Privacy

(No comments)

The Italian Court of Cassation has recently been called on to deal with the issue of whether payment descriptions for bank transfers qualify as sensitive data, in cases in which they specify indemnity payments for illness or disability using the wording “allowance ex L. 210/1992”, (the law which grants allowances to parties who have suffered irreversible complications due to mandatory vaccination and blood transfusions, or in cases of decease, to their families).

The Supreme Court judges have expressed conflicting decisions in several such cases. In all the examined cases, the matter concerned the relations between the Region, which issues the allowance and authorizes the bank transfer, and the ill or disabled party’s bank, which is the recipient of the allowance on behalf of its current account holder.

In the case of the first decision dating from 2014 (judgement n. 10947 of 19th May 2014), the Court considered the payment description, which quoted the above-mentioned legislative references, as sensitive data and thus determined that both the Region and the bank had unlawfully processed personal data since they had not adopted security measures for the transmission and dissemination of said data, such as encryption techniques and non-identifiable codes, as provided for by Art. 22, 6° par. of the Personal Data Protection Code.

In the second decision (judgement n. 10280 of 20th May 2015), which is clearer and better developed than the previous one, the Supreme Court judges overturned their first approach and followed a quite different decision-making process. Firstly, they rejected the concept that payment descriptions for allowances filled out in such a way constituted sensitive data, as the law quoted provided that the recipients of these allowances could either be the parties directly affected or otherwise their families. Since the payment of the allowance did not depend on the illness of the party who actually received it, the judges concluded that the information was not sufficient to reveal the recipient’s state of health and, therefore, did not constitute sensitive data.

Secondly, according to the Supreme Court, it was not a question of the Region rendering the data transferred to the bank public, as this would have implied – in conformity with Art. 4, lett. m) of the Code – disclosure of the data to unspecified parties, whereas in this case the disclosure was only made to the bank of the current account holder who was the beneficiary of the allowance.

Furthermore, the judges considered that references to Art. 22, 6° par. of the Code were groundless, since, as correctly quoted, the adoption of encryption techniques is only required in specific cases where the data originate from directories or registries and the aim is to manage and consult them. Neither could the bank be considered to have the responsibility for adopting these measures for three different reasons: firstly, the provision is only applicable to public bodies; secondly, private entities are only obliged to adopt encryption measures in relation to sensitive data which would reveal a state of health and were processed with electronic systems, both of which conditions are missing in the present case; finally, communicating to a client of the bank’s his/her personal data does not constitute processing of personal data.

Finally, in the opinion of the Court, the role of the bank was that of the current account holder’s representative and it received the payment from the Region on his/her behalf: thus, the payment was to be considered as being directly effected by the debtor (the Region) to the creditor (the recipient of the allowance). Therefore, the Supreme Court considered both the Region’s and the bank’s conduct to be within the law and acknowledged there had been no illegal processing of personal data.

This question has recently once again been deliberated by the 1st Civil Division of the Court of Cassation, which has issued two interlocutory orders (no. 3455 and no. 3456 registered on 9th February 2017) delegating the “Sezioni Unite” (the Joint Divisions), the task of devising a solution to this conflict of case law. On this occasion the Supreme Court has abstained from expressing its own opinion one way or the other with regard to the different interpretations of case law regarding this issue, and has simply commented on the nature of payment descriptions as “sensitive data”. The Court has pointed out that, even if payment can be made both to the family and the ill or disabled party, only the latter would receive payment in instalments (whereas family would receive a lump sum). This particular method of payment would clearly identify the recipient of the payment as the victim of illness or disability and for this reason the indication of a payment in instalments would constitute sensitive data.

We will have to wait to see how the Joint Divisions will solve this conflict of case law we have just described and in particular whether they opt for a broad or restrictive interpretation of the concept of sensitive data.

 

 

  • Recent comments

  • Popular posts

    • None found