Requirements of the GDPR, Part 2

Consider the following:

• An employee loses his or her company-issued computer at the airport, and the information on the drive is not encrypted.
• An employee emails a spreadsheet containing customer names and contact details to the company’s marketing agency, but accidentally sends it to the wrong email address.
• An unencrypted USB thumb drive with customer details is dropped at the train station.
• A malware attack uses compromised user credentials to get access to the customer database, laying bare millions of customer records. What do all four have in common? All are potential data breaches, with a high likelihood of exposing personal data to people who are not authorized to access it. Requirements in the GDPR come into play at two levels in these scenarios:
• Once an organization becomes aware of a data breach of personal or sensitive personal data, it has a 72-hour window to notify the relevant supervisory authority of the breach (Article 33). Article 33(3) specifies four requirements in such a notification: the nature of the personal data breach (including categories of data and approximate number of data subjects impacted), the name and contact details of the firm's data protection officer, an analysis of the likely consequences of the breach, and measures taken or proposed to be taken to mitigate negative effects. The exemption to these requirements is where “the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons,” by for example, having the data encrypted.
• The second requirement is to notify data subjects individually of any personal data breach that has a high risk to their individual rights and freedoms (Article 34), and must contain similar information to that notified to the supervisory authority. There are some exemptions and exceptions noted in Article 34(3), such as if the organization had “appropriate technical and organizational measures” (e.g. encryption) in place to protect the data.

 APPOINTMENT OF A DATA PROTECTION OFFICER (DPO)

Organizations are required to appoint a data protection officer if processing of personal data and/or sensitive personal data is regular and systematic (Article 37), although there are various forms the appointment can take on account of organizational type and size. The data protection officer requires “expert knowledge of data protection law and practices” (Article 37(5)), must have certain freedoms (Article 38), and has a list of prescribed tasks to execute (Article 39). These tasks include informing and advising data controllers, processors, and employees of their obligations under the GDPR, monitoring internal compliance, and cooperating with the supervisory authority, among others.

RIGHT TO DATA PORTABILITY

Data subjects have the right to data portability (Article 20), meaning they can request the personal data they have supplied to a controller in “a structured, commonly used and machine-readable format” in order to give it to another data controller. If technically feasible, the data subject can require the current controller to transmit it directly to the new data controller.

DATA PROTECTION BY DESIGN AND BY DEFAULT

Data controllers are required to design the data protection principles of the GDPR into the very fabric of technical systems and organizational processes (Article 25). This design process is required to consider “the state of the art, the cost of implementation and the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing.” Further, this is supposed to happen when deciding how to carry out a processing as well as when the actual processing takes place.

Article 25 imposes a very high standard on organizations. First, a thoughtful and integrated assessment of four separate factors is required—the state of the art, the cost of implementation, the types of processing, and the associated risk profile. Second, the rights of data subjects per the GDPR need to be understood conceptually and mapped practically to technical capabilities and organizational processes. For example, how will an organization respond to an Article 15 Access request, and how does the technology being used support the access rights of data subjects? This analysis must be executed for the other rights, too, including rectification, erasure, and restriction of processing.

Article 25 has implications for data sovereignty, either when situating data centers in the EU region or by only embracing cloud services that offer jurisdictional assurance of storage, processing, and appropriate security within the EU. Organizations will need to select IT vendors and cloud providers who can demonstrate that the requirements of the GDPR are built-in by design and by default to their respective solutions, not bolted on to legacy architectures that become ever more fragile.

Requirements of the GDPR, Part 3 (Many Other Requirements)