I wouldn't agree that the medium sized companies tried to comply with the GDPR and failed. Yes, they tried to comply with that particular request but the failures suggest that they didn't even try to be GDPR compliant in the first place - if they had done so, then they would have had assigned a data protection officer who would have long ago asked themselves the question "what do we do in case of a personal information request?", and written down a reasonable process for handling such requests, possibly consulting with the local data protection agency.
That would count as "trying", as it was their duty to have done this a year and a half ago. It's basic 'table stakes', a precondition to being permitted to handle personal data at all. If they started thinking about "how do we verify identities" only on day they received the request from this researcher, then that's not trying to comply, that's being grossly negligent.
I keep hearing on Hacker News how easy it is to be GDPR compliant and that any company following good privacy practices should have no problems.
Then I see stuff like:
>if they had done so, then they would have had assigned a data protection officer who would have long ago asked themselves the question "what do we do in case of a personal information request?"
If I have to hire/create an entirely new position at my company these laws are not straightforward or common sense.
In most places it's not a full time position but simply a designation on who's the responsible person.
However, the reason why it's not talked much in context with GDPR compliance is that's not really a new GDPR requirement - it has been a mandatory requirement already in the previous privacy laws; any EU company handling private data had to have a designated DPO for many years before GDPR and that's a nonnegotiable basic requirement if you want to handle such data. If a company doesn't have this, then they weren't permitted to handle private data even before GDPR was concieved. GDPR added some more rights to consumers (such as this right to request) which would require the existing DPO's to adjust procedures.
I mean, does it seem likely to you that your company can implement proper, secure handling of private data without having someone responsible for it? This very discussion shows that it takes some attention and specialized knowledge.
And if you can't pay the 'table stakes', then you're not allowed to 'play the game' - this has many parallels with other regulations. Just as it's reasonable to shut down restaurants for gross hygiene violations and prevent them from operating until/unless they can't handle food properly, it's reasonable to shut down data processing activities for gross 'data hygiene' violations, and prevent them from operating until/unless they can handle private data properly. Just as you can't do various construction and industrial activities without having a designated occupational hazard person (not necessarily full-time), you can't handle private data processing without a designated data protection person. There's nothing novel here.
I’m very skeptical of the idea that, if they didn’t account for this particular attack vector, that must mean nobody thought about GDPR at all. If someone came to me to write a DSR plan, I’d be thinking about how to reliably enumerate all the places we might have personal data, not how to verify that people aren’t impostors. (Does your DSR plan also have to prevent spearphishing your DBAs?)
It's not about an attack vector (which may be uncommon or unexpected) but about a basic process for handling information requests. If you're a data controller, there are a few duties you must satisfy, and handling these requests is a mandatory part.
If you're not prepared (whatever that means in your organization) to receive and answer information requests from customers, then you're not prepared to meed GDPR requirements.
If a company had a reasonable process for identity verification in place, and that process was circumvented by an attacker, then I (and most likely the regulator) would consider that as trying and failing, which is generally not punishable but mandates improvements. However, if the company didn't have any process in place (which seems to be the case in many of these examples) and "just happened" to fail, then I (and, again, most likely the regulator) would consider that as negligence, because they had an explicit duty to "use all reasonable measures to verify the identity of a data subject who requests access, in particular in the context of online services and online identifiers" and did not. The question essentially comes down to "were the measure they used reasonable?"; if you spend a little time thinking about it beforehand you generally get to something reasonable, but if a random employee tries to wing it when the first request comes, then it's plausible that the result will not be reasonable.
And, regarding "Does your DSR plan also have to prevent spearphishing your DBAs?" the answer is not clearly negative - GDPR does require you to take reasonable means to ensure data security, and that could involve taking some steps to both reduce the risk of spearphishing DBAs and steps to ensure that DBAs don't get unlimited unlogged unsupervised access to private data; in any case if a breach occurs by spearphishing your DBAs, you'd need to demonstrate to the regulator that you did take reasonable measures and this wasn't because of pure negligence.
That would count as "trying", as it was their duty to have done this a year and a half ago. It's basic 'table stakes', a precondition to being permitted to handle personal data at all. If they started thinking about "how do we verify identities" only on day they received the request from this researcher, then that's not trying to comply, that's being grossly negligent.