I'm not really seeing the issue here. If the requestor is a user of your services, you presumably have some kind of id for them (like email).
Given that this is not a new law (2018 it became active), you would hopefully have some list of tables with information on users. From there it's select * from tables where user=blah.
Deletion requests are where you'll normally have more issues, but it's best effort. Again, look at how Facebook handle this. They explicitly state that it will take 90 days for all backups to be rolled out, and this is totally fine.
And if you are a small service, the likelihood of you having large amounts of PII on people across multiple services is pretty low.
It's worth noting that IP addresses which can't be matched back to a user are not covered by GDPR, so unless you've been storing every IP from which a user's logged in, then you'll be fine.
But, the real solution here is to only store data for which you have a need, and get consent for the processing which your service requires. Sure, this is harder than the normal YOLO store all the things, but it's probably better both from a storage and liability point of view.
Also, your argument segues from running a business of noteworthy capacity (who may have a problem complying) to small businesses (who won't have the capacity, but also don't store enough data to have a problem complying).
And to be fair, GDPR was npt imposed by elites, it was demanded by an awful lot of consumers in Europe. Maybe you don't like that, but I personally think that breast-feeding mothers shouldn't be censored. So cultural differences are going to cause both of us problems.
I don't agree that GDPR compliance is possible for the small guy. Let me explain why with the example of a small ecommerce business, consisting of one Wordpress site, a server host, a payment service and a delivery service. The user will interact with these 4 in some way. Now let's say a customer "Drek" decides to send support a message like the one I linked to, what are the implications for the company if they want to comply with GDPR using the current infrastructure? (Btw, all "Drek" ever bought was a pair of glasses, a purchase which he immediately regretted and asked a refund for after the purchase was finalized).
What happens? You say we need a (couple of) SELECT-statement(s)? I say we need more than that. Also, I'll tell you right now that doing a SELECT-query isn't something customer support can handle, this is something you ask from a developer or server administrator (== more wasted $$$$). So think about that while we go through the information retrieval process:
(1)-(3) You'll need select-statements, retrieval from log-files (such as access_log and error_log). Text explaining the data and explaining what it is used for. The data should be categorized and machine-readable in a common format. These requirements require a deeper understanding of the systems than just running a Wordpress site with a few plugins.
(4) "the recipients or categories of recipient to whom the personal data have been or will be disclosed;", that includes the payment, hosting and (possibly) delivery services.
(5) "where possible, the envisaged period for which the personal data will be stored, or, if not possible, the criteria used to determine that period;". Again, this requires extra knowledge.
(6) Since we haven't mentioned analytics services or any other privacy invasive service that knows more about the user than what they explicitly provide, this is not applicable in this example. However, it is still applicable for many real-world websites.
(7) Not relevant.
To be fair, the information retrieval can be automated, and a template can be used to compose a GDPR response. However, this does require the company to hire someone competent to do it, and also keep this process up-to-date so that it doesn't conflict with newer versions of Wordpress/plugins. And there WILL be newer versions because exploits are found on a regular basis. The developer will also have to make sure that the data is retrievable, and isn't stored offline or in an inconvenient format (such as the case with compressed logfiles). All of this costs money, and different solutions must be prepared for different systems. If the owner decides to move away from Wordpress to another CMS, he will have to hire someone to also replace the GDPR automation process.
This is not practical for a start-up, or a small business. Unless the infrastructure adapts (again, when?), people will have to write custom scripts/solutions to automate the process.
> And to be fair, GDPR was npt imposed by elites, it was demanded by an awful lot of consumers in Europe.
People are rightfully worried about their privacy, of course we are! But that doesn't give the elites the right to willy nilly impose (because that's what they have done) any solution without at the very least making sure it doesn't infringe upon other rights, and consult experts before writing the law. If they would've bothered to consult a seasoned and non-partisan server administrator, I think GDPR would've looked very differently.
I personally believe that the current infrastructure must change to respect user privacy, but this is not the way to do it.
And aaallll of this doesn't directly address the main issue, which is that the accumulation of laws has caused everyone to become a criminal in one way or another.
4 and 5 should already be covered by your privacy policy, which you can point at or copy paste from. Yes, you need to have thought about this once, but you've done that once and not when a customer asks hopefully! Ecommerce even has easy answers for why and how it is processing data most of the time.
The logfiles argument is generally overblown: the process for someone to establish a valid request for that isn't that typically that easy, and in most cases has the simple solution to not keep logfiles with personal data for long if at all (e.g. many webhosts already will by default or as an option anonymize IPs in logs, and it's not all that difficult to implement in other cases).
For business data, yes, you need to be able to look up customers and what data they've given you - but which business application doesn't allow that already?
I don't want to say it's trivial, but small operations tend to also have a small surface for this, easy oversight over everything, and can get this in order with an initial effort to design privacy policies (and identifying and cleaning up places they maybe were negligent before) and prepare checklists that make handling requests easy. I know plenty small shops that have done this just fine.
You know, you probably have a point on some of this.
Thanks, I may actually start building a WP plugin to help with all of this, as if it's the kind of problem you mention here, then I could probably make a whole bunch of money.
Given that this is not a new law (2018 it became active), you would hopefully have some list of tables with information on users. From there it's select * from tables where user=blah.
Deletion requests are where you'll normally have more issues, but it's best effort. Again, look at how Facebook handle this. They explicitly state that it will take 90 days for all backups to be rolled out, and this is totally fine.
And if you are a small service, the likelihood of you having large amounts of PII on people across multiple services is pretty low.
It's worth noting that IP addresses which can't be matched back to a user are not covered by GDPR, so unless you've been storing every IP from which a user's logged in, then you'll be fine.
But, the real solution here is to only store data for which you have a need, and get consent for the processing which your service requires. Sure, this is harder than the normal YOLO store all the things, but it's probably better both from a storage and liability point of view.
Also, your argument segues from running a business of noteworthy capacity (who may have a problem complying) to small businesses (who won't have the capacity, but also don't store enough data to have a problem complying).
And to be fair, GDPR was npt imposed by elites, it was demanded by an awful lot of consumers in Europe. Maybe you don't like that, but I personally think that breast-feeding mothers shouldn't be censored. So cultural differences are going to cause both of us problems.