Responding to subject access requests

There’s nothing like a data subject access request to force an inter-departmental huddle. For U.S.-based DPOs, the exercise may feel a bit like responding to a litigation discovery request. (Indeed, the role of litigation and privilege concerning SARs is an issue explored in Thomas Shaw’s May 2017 post).

Access to what personal information is gathered and how it’s used is one of the fair information practices (FIPS), already obligatory under Member State law implementing the EU Data Protection Directive, so for seasoned European privacy professionals there may be only modest adjustments needed to an existing SAR policy to conform to the EU’s General Data Protection Regulation before the May 25, 2018 deadline.

For those tackling these rights anew in preparation for the GDPR, however, it is a conceptual and operational challenge. In a recent study, the IAPP found that the risk of failing to comply with data subject requests ranked slightly higher among U.S. companies new to the idea, than it did among their EU counterparts.

And yet, the exercise of developing a SAR response protocol has positive side effects, including increased collaboration throughout the organization and a deeper organization-wide appreciation of what privacy fundamentally means.

Access to what?!

I’m a relatively new DPO, and to my knowledge the IAPP hasn’t received many SARs over the years. But now that our members and customers are getting up to speed on the GDPR a few curious folks are exercising their rights and putting us through our paces well in advance of May. We, of course, want to model best practices so we’re taking up the challenge with vigor – and admittedly feeling the aches and pains of the exercise.

As DPO, the first step is, of course, to consult the GDPR because whatever response program one builds needs to meet not just current legal standards but future ones. The GDPR’s Article 15 is the place to start. It provides, initially, that controllers must give data subjects confirmation as to “whether or not personal data concerning him or her are being processed, and, where that is the case, access to the personal data.” I read the reference to “the personal data” throughout the remainder of Article 15 to be qualified by the initial phrase “concerning him or her,” which is to say personal data regarding others is not responsive to the request and indeed should not be disclosed.

The Article 29 Working Party has issued guidance about the GDPR’s treatment of the right of data portability, addressed in Article 20, and there are many similarities between the rights in terms of the package of personal data assets to be disclosed as well as “ported.” Note, however, that Article 20 permits the data subject to receive and have transmitted to another controller “the personal data concerning him or her, which he or she has provided to a controller,” a potentially narrower subset of personal data than merely data “concerning the subject.” This strongly suggests that personal data concerning a data subject is not simply that provided by the data subject but may include data about a data subject even if generated by the controller, or by some automated means.

A quick check of the definitions under Article 4 shows that “personal data” is broadly defined as “any information related to an identified or indentifiable natural person (‘data subject’)” and that identifiers – which make someone “identifiable” – include identification numbers, location data, and “online identifiers.”

U.S. DPOs note carefully: The types of information considered “personal data” that must be disclosed pursuant to a valid SAR extend well beyond the definition of “personal information” or “personally identifiable information” under many U.S. state data breach laws.

The “personal data” definition is not only a subject of official guidance and interpretation, it is fodder for great discussions on the IAPP privacy listserv. One “inexhaustible list” of personal data under the GDPR is “Cyber Counsel” site. Just presenting the following marketing-related personal data definition (culled from Andrew Sanderson’s listserv post) to your marketing and IT teams is sure to open some eyes:

• Data provided voluntarily by the data subject, such as that captured in online forms or in an online shop.
• Click data, including links in marketing emails, landing pages, and the like.
• Metadata from a mobile device.
• Third party cookies if they can be used to identify a data subject.

It’s important to ensure that the personal data revealed in a SAR response “concern” the requesting data subject, and not someone else. It is also important to exclude information that is not personal data (such as anonymous data, or notations that are purely internal to the controller and its systems, or other information that may not be appropriate to disclose for other valid legal reasons).

Operationalizing the SAR response

Article 15 sets forth the “what” for SAR responses, but Article 12 provides guidance on “how.” As noted above, a complete data dump to the requesting data subject is ill advised. First, it’s imperative that controllers authenticate data subjects submitting SARs. Article 12(6) suggests the controller “may” request additional information to authenticate data subjects when it has “reasonable doubts” about their identity, but establishing a routine method to authenticate them seems like an appropriate security safeguard. Indeed, Recital 64 is much more forceful on this point than Article 12: “The controller should use all reasonable measures to verify the identity of the data subject who requests access, in particular in the context of online services and online identifiers.”

Second, information about data subjects other than the requesting party should be excluded from the SAR response.

Third, consideration should be given to the format of delivery; for instance, an electronically-submitted SAR merits an electronically delivered response, unless the data subject requests otherwise.

Article 12 also requires the controller to respond to the SAR within one month of receiving it, with the opportunity to extend up to two months in certain situations. The information must be provided free of charge unless the request is “manifestly unfounded or excessive” or if – as set forth in Article 15(3) – the data subject requests “further copies.”

To manage the few data subject requests we have received to date, I’ve met several times with a programmer in our IT department who works closely with our member and customer databases and with the leader of our membership services team. Together we have been working on how to create useful reports within the one-month deadline imposed by the GDPR.

As DPO, I receive many of the initial requests by email but I do not personally answer them. That is the responsibility of our membership and IT teams, working together, with my role being to guide the process for GDPR compliance. Although in the short term we will need to respond “manually” to each request, we plan to build a subject access request feature that members and customers can use while logged in to their profile. This has the dual feature of authenticating the data subject and providing instant access to their report, or at least the portions of it that can be developed with an automated query. It is also responsive to Recital 63, which provides that, “where possible, the controller should be able to provide remote access to a secure system which would provide the data subject with direct access to his or her personal data.”

Depending on the data subject, some personal data may not be accessible without the need for a supplemental, manual search and report. Recital 63 contemplates that it’s acceptable to communicate with the data subject to clarify and potentially narrow the scope of the SAR response, particularly when the controller “processes a large quantity of information concerning the data subject.” The ICO’s subject access request guidance also suggests that controllers clarify with data subjects just what data they want since potentially they only seek certain personal data and not everything falling within the GDPR’s scope.

Conclusion

Data minimization and regular data destruction practices are important for GDPR compliance and are core features of the FIPs. But there is nothing like a few subject access requests to drive home the virtues of those practices to the controller, as well as the data subject.

In general, I am pleased we’ve been seeing these requests so early if for no other reason than that they have helped open eyes internally to what “personal data” really is. We all think we know it, but only when one searches for responsive data within the controller’s systems – as defined by the GDPR and not by a U.S. data breach law – does one realize the true breadth of the definition.

What is more, responding to customer requests for their data gives controllers an opportunity to really appreciate what the GDPR is trying to achieve. As the Article 29 Working Party explains in its “data portability” guidance, the data access and portability rights “'re-balance’ the relationship between data subjects and data controllers, through the affirmation of individuals’ personal rights and control over the personal data concerning them.”