Remember that a GDPR request is going to typically come electronically. You won't have a physical item to examine for all its anti-counterfeiting features - you're probably going to have a photograph from a mobile phone to look at.
To me it sounds a bit dubious that you can both have a valid reason for keeping personal information about someone and not have a valid way of verifying that you are actually communicating with them.
What sort of agreement can you enter with someone if you don't know who they are?
> To me it sounds a bit dubious that you can both have a valid reason for keeping personal information about someone and not have a valid way of verifying that you are actually communicating with them.
Suppose I run a matchmaking site that stores a real name, username, and sexual orientation for registered users.
To avoid over-collecting data, that's all I require. I don't need strong verification at this stage because there's little risk if someone creates a fraudulent account, and collecting strong verification can add other data security risks.
However, if someone demands the data already in the system, it's of a presumably real person. And revealing whether user X is gay can be very sensitive information.
I don't think that what you describe is incompatible with GDPR.
In general GDPR allows and requires you to use 'all reasonable measures to verify the identity', and in your particular scenario requiring the same authentication that you usually use would be considered reasonable, and it's likely the only possible reasonable measure - if what you say is all you store, then it's impossible to distinguish between two different John Smiths making such requests, and https://gdpr-info.eu/recitals/no-64/ recommends that you should not request more info just for the purpose of these requests.
In this scenario where the information was provided by the users themselves (if you had collected them otherwise from third parties, that'd be a very different issue) simply putting a link "download your data here" on your site for authenticated users would be a reasonable solution; and it matches https://gdpr-info.eu/recitals/no-63/ recommendation "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."
Yeah, there is some weird subtext to the argument, that for some reason account access shouldn't count as secure verification?
I guess this all hinges on the idea that to implement GDPR all you need to do is set up an email adress and handle all requests manually, only to then discover that: actually, identity management via plaintext email is a bit tricky.
Yeah, there is some weird subtext to the argument, that for some reason account access shouldn't count as secure verification?
It's not in dispute that account access using known good credentials would be reasonable verification. But people forget passwords or mistype email addresses or lose access to email accounts, and they still have legal rights as data subjects under the GDPR.
So, it also matters whether other forms of identification are acceptable. If you have some reasonable means of confirming someone's identity in response to a request under GDPR and you try to avoid using it because the person didn't follow your preferred method based on standard account credentials, it's not clear that regulators would accept that as reasonable. And any time the words "not clear" appear, they come with an implicit threat of severe penalties in GDPR world.
This does seem quite explicit - "If you have some reasonable means of confirming someone's identity in response to a request under GDPR" then you have to use them even if they're not your preferred means. In the scenario proposed above the company wouldn't have to confirm the identity only because they can't.
If someone loses their password and asks for their data under the GDPR it's an open question whether the site can simply say "sorry, there's no longer any way for us to verify you are who you say you are".
Ah, that's actually simple - the answer depends on whether that statement is true or not.
In the abovementioned case where only name (which is not unique) and password and sexual orientation is stored, and literally nothing else, you can say "sorry, we took all reasonable measures to verify your identity, and couldn't" because that's how it is.
However, if google or paypal or someone else who stores much more data says "sorry, there's no longer any way for us to verify you are who you say you are", then that's a lie (easily verifiable by the regulator), and that's not acceptable.
So you say you store sexual orientation connected to a real name, that this information is sensitive, and that you have shoddy account security?
If someone wants to download account information they just have to log in and press the button on the appropriate page, and either get the data directly or else some special token to prove account ownership.
If account access is not secure enough, then what business do you have storing the information at all?
Remotely we generally use digital verification, my ID card has a secure chip that's usable for online authentication (available to third parties by redirect through a gov't website) and for e-signatures of digital documents; so I could send a GDPR request in a PDF where the recipient can verify that this indeed was signed by Name Surname ID123. However, things like this are still a bit fragmented between different EU countries, some harmonization would be really helpful for cross-border businesses and it will probably take many years.
What I'm probably saying is that the question "is a GDPR request-er providing valid ID" is solvable; it's not solvable easily (yet) but this BlackHat experiment shows that large companies already can do it internally and smaller companies probably can outsource it to someone who can do the required integrations/processes to match all the EU states.
