The European Data Protection Board has published draft guidelines on the right of access, for consultation.

These are draft guidelines, and so they may change before they are made official.

To save you wading through the 60 page consultation draft, here are five bits I found interesting.

(If you are not sure what the right of access is about, here is our primer.)

If a data subject wants all their data, they can have all their data (subject to exemptions)

It is not a particular surprise that, if a data subject wants all their data, they can have all their data (subject to exemptions), but the EDPB sets this out clearly, along with the circumstances in which a controller is justified in asking a data subject to confirm what they want.

The draft guidance says that:

Unless explicitly requested otherwise by the data subject, a request to exercise the right of access shall be understood in general terms, encompassing all personal data concerning the data subject.

If the controller processes a "large amount of data concerning the data subject", such that the controller has a genuine doubt as to whether the data subject wants everything, the controller may ask the data subject to specify the data they wish to obtain.

However, it is open to the data subject to respond asking for everything:

It is important to underline that the request for specification shall not aim at a limitation of the reply to the access request and shall not be used to hide any information on the data or the processing concerning the data subject. If the data subject, who has been asked to specify the scope of its request, confirms to seek all personal data concerning him or her, the controller of course has to provide it in full.

Later on, the guidance says that the fact that this may entail a great deal of effort does not render the request complex (such that a controller can decline):

The mere fact that complying with the request would require a great effort does not make a request complex. Neither does the fact that a big company receives a large number of requests automatically trigger an extension of the time limit. However, when a controller temporarily receives a large amount of requests, for example due to an extraordinary publicity regarding their activities, this could be regarded as a legitimate reason for prolonging the time of the response.

If a controller keeps personal data for only a short period of time, it must handle access requests sufficiently quickly, to enable it to respond to requests for those data

Some personal data are ephemeral - for example, as CCTV system which only retains recorded images for a few days, or a server log which gets overwritten within hours if a site's traffic volume is high.

While the GDPR provides for up to a month to respond to requests, the EDPB's position is that, if the controller processes personal data for less than a month, the controller must be able to respond to access requests in a sufficiently timely manner, to enable it to provide these data:

the controller shall implement the necessary measures to facilitate the exercise of the right of access and to deal with such requests as soon as possible and before the data will have to be deleted. In the case of shorter retention periods than the timeframe to answer imposed by Art. 12(3) GDPR, the timing to answer the request should be adapted to the appropriate retention period in order to facilitate the exercise of the right of access and to avoid the permanent impossibility of providing access to the data processed at the moment of the request.

In other words, a controller cannot sit on its hands and wait for automatic deletion of the personal data, and then explain to the data subject that it no longer has them to provide.

This feels like it could be challenging, especially for systems with very short retention periods.

It also has an implication for requests which are made very close to the expiry of the retention period. If a controller's transparency information shows that it retains CCTV for, say, 10 days, and the data subject puts in a subject access request towards the end of the final day, the implication of the guidance is that the controller must drop everything to handle the request.

I wonder if this particular bit will survive the consultation without clarification or qualification.

A controller can only ask for additional identity information, to verify a data subject's identity, within tight limits

If a controller can identify a data subject without requiring additional information from the data subject, it must do so.

For example, if a user is authenticated - logged in - that would seem to be sufficient:

it is disproportionate to require a copy of an identity document in the event where the data subject making their requests are already authenticated by the controller.

Asking for a copy of an identity document is particularly restricted:

using a copy of an identity document as a part of the authentication process creates a risk for the security of personal data and may lead to unauthorised or unlawful processing, and as such it should be considered inappropriate, unless it is strictly necessary, suitable, and in line with national law.

Moreover, a controller can only require an unredacted copy of an identity document where that is required by law:

In any case, information on the ID that is not necessary for confirming the identity of the data subject, such as the access and serial­ number, nationality, size, eye colour, photo and machine­ readable zone, may be blackened or hidden by the data subject before submitting it to the controller, except where national legislation requires a full unredacted copy of the identity card.

In other words, a policy of demanding a passport or driving licence in every situation is unlikely to be sustainable. Again, this one is not a particular surprise, but the clarification is welcome.

A controller need not respond using a third party portal

A number of organisations have popped up, offering data subjects a portal through which they can submit access requests to controllers, asking for a response to be sent back solely via that portal.

Quite why these tools are useful, I am not sure, and they can, in practice, be a pain for controllers.

Controllers must handle requests received through portals, as normal, but:

There is, however, no obligation for the controller to provide the data under Art. 15 directly to the portal. If the controller, for example, establishes that the security measures are insufficient, it would be deemed appropriate to use another way for the disclosure of data to the data subject. Under such circumstances, when the controller has other procedures in place to deal with access requests in an efficient way, the controller can provide the requested information through these procedures.

It is unclear - this is draft guidance - whether a controller must have a valid reason for not using the portal, or whether the fact that there is no obligation means that the controller has full discretion as to whether to respond using the portal.

I am hopeful that it is a broad discretion, to avoid any obligation on the part of a controller to assess a portal's suitability or security, or to liaise with their IT security team to grant access to the portal to upload personal data.

Information created by a fraudster can still be within the scope of the right of access

This is an interesting bit of guidance, going to the heart of what is "personal data":

In case of identity theft, a person fraudulently acts in the name of another person. In this context it is important to recall that the victim should be provided with information on all personal data the controller stored in connection with their identity, including those that have been collected on the basis of the fraudster’s actions.

It is not clear from the guidance whether, if the controller has identified that the information in question is fraudulent, and has flagged or tagged it in that way, it still falls within the definition of "personal data", and thus the right of access.

Personally, I am sceptical that, say, a recording of a call between a fraudster and a controller, in which the fraudster pretends to be a data subject, is the personal data of that data subject, if it is identified by the controller as fraud.