Thanks for the comment. It actually perfectly illustrates my point. Most people equate GDPR with a "Delete My Account" button, but that’s just the tip of the iceberg.
We didn't spend thousands of hours on a deletion feature (or just development time). We spent them in total to be compliant in a healthcare environment. That time goes into:
Documenting the entire lifecycle (how, why, and where) of every single data point we process. Conducting and documenting formal risk assessments for every major processing activity (Privacy Impact Assessments (DPIA)). Drafting and negotiating data processing agreements (DPAs) with every single partner and vendor we use. Building strict role-based access and logging systems to track exactly who views and edits data and why. Implementing pseudonymization and logical data separation to ensure we meet "privacy by design" standards. Constantly coordinating between the product and dev team and the DPO to update policies and communicate changes to users.
The point I’m making is that the EU has built an incredibly expensive regulatory environment to support rights that, in practice, the vast majority of users don't seem to care about. We’re over-engineering for a "loss of control" that the average user hasn't shown much interest in reclaiming.
Those things are all necessary anyway, apart from the last one (communicate to users) which absent GDPR is a nice-to-have. If you don't do them, or something equivalent to them, then your processes will be wrong and you'll have breaches – and breaches of healthcare data are extremely bad. What GDPR gives you is the assurance that you won't be at a competitive disadvantage for doing the bare minimum due diligence, because your competitors are required to do so, too.
> We spent thousands of hours building systems for rights that only 0.001% of our users cared to use.
GDPR does not require that any of the data subject rights are automated, other than "right to be informed" (which it doesn't explicitly spell out has to be automated, but "put the information on the website" is the easiest way to comply if you're relying on the consent basis for anything). If you expect that under 200 people are ever going to exercise a particular right, and automation will take longer than manually fulfilling those requests, then don't automate them: just add it to your DPO's job description.
> that, in practice, the vast majority of users don't seem to care about.
You can't use "people are choosing not to waste the time of a healthcare provider" as an argument that people don't care. They may simply be being kind. I very rarely require GDPR data subject access requests, but when I do, it's very important that I can get them in a timely manner.
If I know what information is kept by the organisation (and therefore would be included in the GDPR request), and there are other ways of me accessing the information I care about having, I don't need to perform a GDPR request. It's organisations where there aren't where I'm most likely to need to make a GDPR request. If a company is actually complying with data minimisation and purpose limitation, I do not need to make a GDPR deletion request. etc etc. I think you're focusing on how annoying it is for you, and not thinking of the impact on your less-ethical competitors (who might otherwise be able to run you out of business – depending on the industry).
I think you’re conflating security with compliance.
If the goal is to stop breaches, we should mandate MFA and ban default-public cloud buckets. Those are technical solutions. GDPR, instead, mandates a massive administrative layer. No data breach has ever been stopped by a well-drafted Privacy Impact Assessment or a 50-page DPA. Those are legal shields, not security measures.
> then don't automate them: just add it to your DPO's job description.
The DPO isn't an engineer. To let them fulfill a request, I still have to build the internal tooling to query, redact, and export data from distributed production databases. Also, "I'll have my DPO do it manually" never sounds good when going through an audit.
> they may simply be being kind.
The simpler explanation is that the average person has no clue what these rights are because they’ve never had a reason to care. In healthcare, patients care that their data is secure and the service works. They aren't losing sleep over "data portability."
Ultimately, this "level playing field" only benefits incumbents. Unethical players ignore the rules until they’re caught, while legitimate startups are hit with a compliance tax that makes it nearly impossible to compete with US-based firms that can focus 100% of their energy on the product.
> Those things are all necessary anyway
It's a bold statement. Have you ever actually been working on any compliance yourself? 80% of everything is just senseless bureaucracy. I've worked in a medical startup and we had it all: GDPR, HIPPA, FDA approvals etc. The requirements are completely detached from reality and are usually written for some X-Ray producing firms from 20th century, not an health-tech AI startup. And they're trying to regulate everything, even how your organizational structure should look like, how you should create tickets in Jira (or any other _compliant_ products). Developers had to take useless trainings on how a medical organization should operate, which were essentially the courses of Aesopian language of medical bureaucracy. And legal expenses, boy o boy, the company had to spend twice as much on compliance staff than it did on developers. And what was the result? Rich American competitors with a ton of VC money were getting approvals while our company was struggling with all this idiocy despite having a much more superior product.
Thanks for the comment. It actually perfectly illustrates my point. Most people equate GDPR with a "Delete My Account" button, but that’s just the tip of the iceberg.
We didn't spend thousands of hours on a deletion feature (or just development time). We spent them in total to be compliant in a healthcare environment. That time goes into:
Documenting the entire lifecycle (how, why, and where) of every single data point we process. Conducting and documenting formal risk assessments for every major processing activity (Privacy Impact Assessments (DPIA)). Drafting and negotiating data processing agreements (DPAs) with every single partner and vendor we use. Building strict role-based access and logging systems to track exactly who views and edits data and why. Implementing pseudonymization and logical data separation to ensure we meet "privacy by design" standards. Constantly coordinating between the product and dev team and the DPO to update policies and communicate changes to users.
The point I’m making is that the EU has built an incredibly expensive regulatory environment to support rights that, in practice, the vast majority of users don't seem to care about. We’re over-engineering for a "loss of control" that the average user hasn't shown much interest in reclaiming.
Those things are all necessary anyway, apart from the last one (communicate to users) which absent GDPR is a nice-to-have. If you don't do them, or something equivalent to them, then your processes will be wrong and you'll have breaches – and breaches of healthcare data are extremely bad. What GDPR gives you is the assurance that you won't be at a competitive disadvantage for doing the bare minimum due diligence, because your competitors are required to do so, too.
> We spent thousands of hours building systems for rights that only 0.001% of our users cared to use.
GDPR does not require that any of the data subject rights are automated, other than "right to be informed" (which it doesn't explicitly spell out has to be automated, but "put the information on the website" is the easiest way to comply if you're relying on the consent basis for anything). If you expect that under 200 people are ever going to exercise a particular right, and automation will take longer than manually fulfilling those requests, then don't automate them: just add it to your DPO's job description.
> that, in practice, the vast majority of users don't seem to care about.
You can't use "people are choosing not to waste the time of a healthcare provider" as an argument that people don't care. They may simply be being kind. I very rarely require GDPR data subject access requests, but when I do, it's very important that I can get them in a timely manner.
If I know what information is kept by the organisation (and therefore would be included in the GDPR request), and there are other ways of me accessing the information I care about having, I don't need to perform a GDPR request. It's organisations where there aren't where I'm most likely to need to make a GDPR request. If a company is actually complying with data minimisation and purpose limitation, I do not need to make a GDPR deletion request. etc etc. I think you're focusing on how annoying it is for you, and not thinking of the impact on your less-ethical competitors (who might otherwise be able to run you out of business – depending on the industry).
I think you’re conflating security with compliance.
If the goal is to stop breaches, we should mandate MFA and ban default-public cloud buckets. Those are technical solutions. GDPR, instead, mandates a massive administrative layer. No data breach has ever been stopped by a well-drafted Privacy Impact Assessment or a 50-page DPA. Those are legal shields, not security measures.
> then don't automate them: just add it to your DPO's job description.
The DPO isn't an engineer. To let them fulfill a request, I still have to build the internal tooling to query, redact, and export data from distributed production databases. Also, "I'll have my DPO do it manually" never sounds good when going through an audit.
> they may simply be being kind.
The simpler explanation is that the average person has no clue what these rights are because they’ve never had a reason to care. In healthcare, patients care that their data is secure and the service works. They aren't losing sleep over "data portability."
Ultimately, this "level playing field" only benefits incumbents. Unethical players ignore the rules until they’re caught, while legitimate startups are hit with a compliance tax that makes it nearly impossible to compete with US-based firms that can focus 100% of their energy on the product.
1 reply →
Another thing that was just recently examined (in this case by the french privacy authority) is the savings given by applying gdpr https://www.cnil.fr/en/economic-impact-gdpr-5-years
https://www.cnil.fr/en/economic-impact-gdpr-5-years
unfortunately the whole texts are in french
> Those things are all necessary anyway It's a bold statement. Have you ever actually been working on any compliance yourself? 80% of everything is just senseless bureaucracy. I've worked in a medical startup and we had it all: GDPR, HIPPA, FDA approvals etc. The requirements are completely detached from reality and are usually written for some X-Ray producing firms from 20th century, not an health-tech AI startup. And they're trying to regulate everything, even how your organizational structure should look like, how you should create tickets in Jira (or any other _compliant_ products). Developers had to take useless trainings on how a medical organization should operate, which were essentially the courses of Aesopian language of medical bureaucracy. And legal expenses, boy o boy, the company had to spend twice as much on compliance staff than it did on developers. And what was the result? Rich American competitors with a ton of VC money were getting approvals while our company was struggling with all this idiocy despite having a much more superior product.
2 replies →
I'd wager it's less expensive than US medical services.