In 2016, the Westin Research Center published a series of articles identifying our analysis of the top 10 operational impacts of the European Union’s General Data Protection Regulation. Now, with the May 25, 2018, GDPR implementation deadline looming, the IAPP is releasing a companion series discussing the common practical organizational responses that our members report they are undertaking in anticipation of GDPR implementation.

This seventh installment in the 10-part series addresses data subjects’ rights. The GDPR empowers data subjects with individual rights that include being informed, requesting access to their information, obtaining and reusing their data across different platforms (data portability), rectifying and erasing their personal data, objecting to automated processing, and withdrawing their consent under some circumstances. The previous installments of the series can be found here.

Establishing and improving processes to respond to data subjects’ requests

Accommodating data subjects’ rights can be one of most nuanced and challenging areas of GDPR implementation. Indeed, as the IAPP-EY Annual Privacy Governance Report 2017 demonstrated, data portability, the right to be forgotten, and gathering explicit consent are perceived as the most difficult issues for privacy professionals. One suggested way of tackling these issues is not to consider them as separate workstreams, but to think of them as the same question asked in different ways. 

Generally speaking, data subjects can request access to a copy of their personal data and to a variety of other information, such as the purpose of processing, categories of data that are processed, information on the parties to which their personal data have been disclosed (specifically, recipients in third countries), and retention periods. In addition, responses to these requests need to be given within a short time frame. Data subjects have the right to request rectification of inaccurate personal information “without undue delay,” or to have incomplete personal information completed. Similarly, the right to be forgotten gives data subjects the right to request the erasure of their personal data “without undue delay” under certain circumstances (e.g., when the personal data is no longer necessary for the collection purposes, when consent is withdrawn, or when the processing is unlawful).

In addition to having systems for deletion in place, organizations also need to be capable of halting processing activities, as individuals can also ask to restrict the processing under certain circumstances, including when the accuracy of the data is contested, the processing is no longer necessary, or when the subject objects to it. Organizations also need to create communication channels where they can inform recipients about erasure or rectification of data unless such a task can be proved to be impossible. Individuals can also request their data be transferred to another controller and object to data processing under certain circumstances.

Individuals’ rights, their application, and limitations to them are crafted in detail under the GDPR. To be able to actually respond to data subjects’ rights in practice, the Irish Data Protection Commissioner (DPC) suggests asking the following questions as part of an organization’s GDPR readiness checklist: 

• Is there a documented policy or procedure to address Data Subject Access Requests (now commonly referred to as DSARs)?
• Is your organization able to respond to DSARs within one month?
• Are there procedures in place to provide personal data to data subjects in a structured, commonly used, and machine-readable format?
• Where applicable, are there mechanisms in place to allow personal data to be deleted or rectified?
• Are there mechanisms in place to stop the processing of personal data when a data subject seeks to restrict the processing?
• Are individuals informed about their right to object to certain types of processing?
• Are there mechanisms in place to stop the processing of personal data when individuals object to it? 

Building upon established systems

The first step to creating a data subject response system is to find out what is already in place. Does the organization have procedures for channeling customer questions to people who have the ability to validate the customer’s identity and respond meaningfully to the request? Is there a pattern and practice of involving the data protection officer in the chain of communication? How are records of requests and responses currently kept, including records of how long it takes to respond?

Data subjects need a way to exercise their rights — either independently through an automated system or by contacting the organization directly. Making this process transparent and easy is key not only to good customer relations and to fulfilling the organization’s transparency obligations, but to ensuring that data subjects feel comfortable bringing their complaints directly to the organization and not, at least at first, to the regulator.

Automation

Some organizations maintain customer information in accounts specific to the customer and to which the customer may have access, perhaps via a user name and password. Such systems can empower data subjects to maintain the accuracy of their own records, and possibly even gain access to at least some of their personal data the organization processes. Indeed, Recital 63 encourages controllers, where possible, to provide “remote access to a secure system” that allows direct access to the data subject’s personal data. Such subject access processes must be built with database management and programming staff and without compromising security.

The simplicity suggested by Recital 63 belies a fundamental dilemma controllers face, however. Indeed, one of the major issues confronting data controllers is the extremely broad definition of personal data. For data mapping and inventory exercises, as well as for lawful basis assignment and the like, many categories and types of personal data may be identified and steps taken to segregate direct identifiers from indirect ones. But even indirect identifiers may fall under the scope of a general data access requests. In their guidance on data portability, the Article 29 Working Party states that, in addition to the data that is “actively and knowingly provided by the data subject,” observed data provided by the data subject by virtue of the use of the service or device (e.g., search history, location data, and “raw data” tracked by a wearable technology) may fall under data “provided by the data subject” and be covered by the right to access and portability.

Recital 63 provides that, when the controller processes a large quantity of information concerning a data subject, the controller may request that the data subject “specify the information or processing activities to which the request relates.” Most data subjects will seek only the most basic, directly identifying, profile information, which may be more easily automated. And Recital 64 clearly counsels against keeping data subject to routine destruction merely to respond to a potential access request. Still, for many controllers, the potential scope of “personal data” responsive to subject access requests will be very broad indeed and practical solutions for minimizing operational headaches are elusive.

People, process and technology

Article 37(4) provides that data subjects should be able to contact an organization’s DPO for “all issues related to processing of their data and to the exercise of their rights.” Accordingly, the ideal first point of contact for data subjects is the DPO, which should be clearly stated in privacy notices and other data subject communications.

Because the DPO is not likely to also have the job of inputting, correcting, or deleting data, and indeed should be free from conflicts of interest in that regard, the DPO will need to develop a system for working with others to evaluate and respond to data subjects. This system must record the time of the response, the unit or the person that responded to the request, as well as an explanation of the response. While this might be carried out in manual processes at the beginning through spreadsheets — depending on the extent and the frequency of the data subject requests — technological tools or more sophisticated solutions may be used. Currently, most organizations manually manage processing involving data subjects’ rights, but there are also tools in the market for these tasks. Currently, these technologies do not yet seem to have been significantly incorporated into businesses practices, but this may vary depending on the maturity of the market and organizational needs.

There is nothing like receiving a data subject request to focus the mind on the problem. But for those organizations anticipating such requests, a good strategy is to prepare standard templates with answers to questions that most people are likely to ask — such as types of data collected about them, collection methods, and retention policies. This information should already be readily available to data subjects in publicly accessible privacy notices, but placing it at the hands of customer service personnel is also key.

Importantly, as much as building new systems and responding to requests costs an organization time and money, responses to DSARs should be free of charge — or for a “reasonable fee” if the request is excessive — and without delay. In case an organization does not accept the DSAR, they need to provide reasons for it and inform the data subject that they have a right to complain about it to their local data protection authority.

Costs and response times can be minimized if databases containing personal data are searchable and as accurate as possible. Strictly adhering to data destruction policies can also ease the burden of responding to DSARs and other requests, including rights of erasure. The GDPR is clear that data should not be retained merely in anticipation of data subject requests. In some places, the system might not be set up well due to either data being spread across multiple systems or data not being recorded correctly. Organizations should regularly audit their systems to ensure data collection and retention procedures are clear and enforced.

Portability

Data subjects have a right to receive their personal data that they have provided to the data controller “in a structured, commonly used and machine-readable format” when the data is processed by “automated means.” In addition, they can request data controllers to transmit their personal data to another controller “when technically feasible.” While the GDPR does not oblige data controllers to “adopt or maintain” “technically compatible” systems, they are “encouraged to develop interoperable formats that enable data portability.” The Article 29 Working Party suggests paying “special attention” “to the format of the transmitted data, so as to guarantee that the data can be re-used, with little effort, by the data subject or another data controller.”

Organizations, therefore, need to ensure that the applications and systems that house the data can port personal data easily. The Article 29 Working Party recommends data controllers begin to develop the means by which data portability requests will be answered, such as through download tools or application programming interfaces. Most data controllers may prefer the use of an “automated tool that allows extraction of relevant data” when large and complex data sets are involved, as this can minimize privacy risk.

These tasks may not, however, be as straightforward as organizations wish, especially those that have unstructured data. Organizations need a deployable and easy-to-use tool that can help them to mine unstructured data. This seems to be an area where organizations are in most need of automated solutions, as right now they are mainly relying on manual processes.

Erasure

The GDPR provides that data subjects have the right to request erasure of their personal data from the controller on certain conditions, such as when:

• “[T]he personal data are no longer necessary” for the original purposes of data collection or processing.
• The data subject withdraws the consent which was the basis of data processing, and when “there is no other legal ground for the processing.”
• The data subject objects to data processing and “… no overriding legitimate grounds for the processing” exists.
• “The personal data have been unlawfully processed.”
• The erasure is necessary to comply with the Union or member state law.
• The personal data was collected in relation to services referred in “conditions applicable to child’s consent,” such as if the data subject gave his or her consent as a child but was unaware of the risks. 

Moreover, to strengthen this right in the “online environment,” data controllers that have made the personal data public and are required to erase the data have to take reasonable steps to inform controllers who “are processing such personal data to erase any links to, or copies or replications of those personal data,” in light of “available technology and cost of implementation.”

The scope and practical application of the right to be forgotten and the right to erasure, however, have been the subject of heated debate, and these rights are not absolute. Obligations on data controllers to erase personal data and inform third parties do not apply “to the extent that processing is necessary” for various reasons, including:

• Exercising freedom of expression and freedom of information.
• Complying with Union or member state law.
• Performing a task for the “public interest…in the area of public health” or “for archiving purposes…scientific or historical research purposes,” or “in the exercise of official authority vested in the controller.”
• Establishing, exercising, or defending legal claims.

Practically speaking, moreover, organizations may find that maintaining a data subject’s contact information is necessary to prevent communicating with the data subject in the event they request not to be contacted. 

Where GDPR deletion requirements conflict with EU member state archiving requirements, organizations should set up a schedule for archiving per document and per data set, which would include a maximum period of storage or the length for which the data can be only held for that purpose.

Authentication 

Finally, most privacy professionals are concerned with making sure the request is legitimate and comes from the actual data subject. There are several reasonable steps data controllers can take to authenticate individuals, requiring users to provide “something one knows (e.g. passwords or passphrases), something one has (e.g. a security token) and something one is (e.g. biometric information).”

Decision-making around accommodating data subjects rights is not a single-person activity. Rather, it is a team-driven effort involving people who know the business, lawyers and privacy professionals that know the extent of the law and legal requirements, employees from human resources that deal with a variety of information, and IT teams that have the relevant knowledge about data systems, processes and data transfers.

Conclusion

To ease the challenges associated with configuring systems to accommodate data subjects’ rights, it is critical to be aware of the systems and processes in place as well as constantly work to find ways to address weaknesses. Most importantly, it is essential to strengthen communication with people from different departments and work together to understand the expectations of data subjects, while focusing on the most-likely scenarios.

Photo credit: V. Sharma If suffering brings wisdom, I would wish to be less wise via photopin (license)