Consider the following:
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.
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.