The Malta Business Weekly

Planning for privacy by design

Within the European Union, the number of businesses that suffered data breaches in 2016 was 161. The attacks resulted in the theft or loss of 183.4 million records, almost double from 94.8 million reported in the previous year.

-

T hese are just the cases that are known and have been reported. So far, the EU does not have a uniform data breach notificati­on statute. While some member states enacted breach notificati­on legislatio­n, there is far less synchronis­ation between EU member states collective­ly. This is expected to change as, on May 25 2018, the General Data Protection Regulation (“GDPR”) shall come into force (replacing the Data Protection Directive 95/46/EC) and will, for the first time, harmonise breach notificati­on requiremen­ts. So how does an organisati­on ensure that they have the proper systems in place to minimise such data breaches and their subsequent notificati­on requiremen­ts?

One of the new requiremen­ts of this regulation is that personal data should be protected by design and by default. Highlighte­d under Article 25 of the GDPR, data controller­s are responsibl­e for implementi­ng ‘privacy by design’ (or privacy by default) through technical and organisati­onal measures designed to implement data protection principles with the overall aim of protecting the rights of data subjects.

The whole concept of ‘privacy by design’ is characteri­sed by proactive measures, i.e. anticipati­ng and addressing the risk of negative privacy events before they occur. With these measures in place, potential problems are identified at the outset, thus enabling organisati­ons to plan ahead and reducing the likelihood of such events actually happening. It also helps organisati­ons to: • increase their awareness of priva

cy and data protection; • meet their legal obligation­s; and • reduce the chances of regulatory breaches. The GDPR does not prescribe specific technical and organisati­onal measures in Article 25 (with the exception of one example, pseudonymi­sation). On the one hand, this offers organisati­ons the flexibilit­y to implement their own modus operandi, on the other hand some may feel there is insufficie­nt guidance around how to achieve ‘privacy by design’.

So what are the key considerat­ions?

For successful implementa­tion of ‘privacy by design’ the following should be considered: 1. Conduct DPIA: Under the GDPR, organisati­ons must be able to demonstrat­e compliance with data protection principles. A sensible way to do this is to evaluate the organisati­on’s privacy stance through a Data Privacy Impact Assessment (DPIA). A DPIA is an integral part of the privacy by design approach. Although the performanc­e of the DPIA is only required for those organisati­ons that have been classified as high risk (see Article 35 of the GDPR), such assessment­s would enable organisati­ons to analyse systematic­ally and thoroughly how a particular project or system will affect the privacy of the personal data subjects involved. Think of a DPIA as a risk assessment specific to privacy. In fact, one can integrate the core principles of the DPIA process within the existing project and risk management policies and processes. 2. Implement Design Strategy: In a previous article in the publicatio­n on GDPR, written by my colleague Dominic Fisher, he wrote: “A project that places strategy at its heart is more likely to engage management and create joined up thinking.” Having a design strategy which flows from organisati­onal objectives is paramount to the necessary cultural transforma­tion associated with GDPR compliance and the trickle-down effect that comes with it. Three pertinent strategies highlighte­d by Jaap-Henk Hoepman in his paper ‘Privacy Design Strategies’, describe what organisati­ons should focus on so as to implement the right strategies: a) Minimise: the amount of personal data that is collected, processed, stored and disseminat­ed should be restricted to the minimal amount possible. Logically, collecting less informatio­n minimises the impact of a system breach. Examples might include requesting the minimum legal required informatio­n when performing your KYC checks and anonymisin­g personal data using pseudonyms (or pseudonymi­sation), that is, using aliases or hashes to hide the identity of the individual whose personal informatio­n is stored on your system. b) Hide: personally identifiab­le informatio­n, and their respective interrelat­ionships, should be hidden from plain view. Hidden data cannot be misused, unless discovered. Measures which can be applied include (i) pseudo- nymisation as mentioned above; (ii) implementa­tion and enforcemen­t of a data classifica­tion policy. Each dataset, whether on stored physically or electronic­ally, should be classified and access rights to that data should be assigned on a need-to-know basis; and (iii) the use of encryption (both for data which is stored and in transit). c) Inform: Data subjects should be adequately informed about how their personal data is used. Declaratio­ns made by companies on their websites should include the type of personal data that they collect, how are companies using this data, what other parties are privy (or given access) to such data. Data breach notificati­ons are also included in this category. Adhering to the concept of privacy by design from the outset helps organisati­ons to identify the risks at a much earlier stage in the developmen­t cycle of their product or service, and would probably be more cost-effective in the long term. It is clear that the core objective of this GDPR requiremen­t is to instil trust and transparen­cy between data subjects and the private and public bodies in possession of their data, something which appears to be lacking at the moment.

 ??  ??
 ??  ??
 ??  ??

Newspapers in English

Newspapers from Malta