So deletion of user accounts meant thousands of hours of development time?
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.
> 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).
https://www.cnil.fr/en/economic-impact-gdpr-5-years
unfortunately the whole texts are in french
I'll note that of the three regulatory acronyms you gave, two of them (HIPPA and FDA approvals) are American.
I specified all three via comma to highlight that we had quite some history in compliance, in different jurisdictions.
HIPPA covers only medical devices, GDPR covers everything. FDA approval process is convoluted and expensive, especially for new types of devices, but it's still much easier than European MDR.
Also, I mentioned FDA because we didn't even try to get a proper compliance in the EU, because it's impossible for a startup without huge support.
No, the HIPAA Privacy Rule covers only medical information: see https://www.hhs.gov/hipaa/for-professionals/privacy/laws-reg.... Perhaps with your organisation, this was restricted to devices, but within a hospital environment there's a lot more covered by the HIPAA Privacy Rule than just medical devices. NB: the combined text of the applicable HIPAA rules (115 pages) are a lot longer than the entire text of the GDPR (88 pages, including recitals).
> but it's still much easier than European MDR
While MDR doesn't cover everything, it's still only 123 articles long: https://eur-lex.europa.eu/eli/reg/2017/745/2026-01-01. I'm guessing the burdensome parts are in SECTION 2: Conformity assessment. The EU recently ran a consultation on this: https://ec.europa.eu/info/law/better-regulation/have-your-sa.... A lot of problems seem to be due to the article 56 (2) requirement:
> The certificates shall be valid for the period they indicate, which shall not exceed five years. On application by the manufacturer, the validity of the certificate may be extended for further periods, each not exceeding five years, based on a re-assessment in accordance with the applicable conformity assessment procedures.
Other than that, it just seems like "do actual science to determine safety" and "if there's no 'intended medical purpose', also do actual science to demonstrate efficacy". The HMT Medizintechnik GmbH consultation feedback seems to say that a small company providing, say, basic sutures, is required to repeatedly prove the adequacy of those sutures, even though everybody knows that basically any sutures are adequate for those cases where sutures are adequate; but I don't think that's a correct reading of the law. (And this shouldn't affect a new device.) So I'm a bit confused. https://www.medtecheurope.org/wp-content/uploads/2025/03/250... clinical evaluation TOP 3 (on page 18) does not describe a problem with the text of MDR, but as a long-term mitigative measure they suggest:
> Possibly making this clearer in the text revision so Notified Bodies do not feel they must ask for PMCF clinical investigations as a default.
You never claimed that the text of the regulation was the issue; and I think I'm starting to see where the problem lies. While the rules are mostly sensible, they delegate to national bodies empowered to exercise discretion, and these bodies are (reportedly) erring on the side of excessive requirements. Was this the reason you gave up on EU certification without attempting it?
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.
> ban default-public cloud buckets
GDPR Article 5 1(f) already bans those. It doesn't mandate MFA in particular, but it does mandate "protection against unauthorised or unlawful processing […] using appropriate technical or organisational measures". There's a reason that GDPR doesn't get more specific than that. If you're at all familiar with the Microsoft stack, you'll know that mandated security checklists often come at the expense of actual security (see also: AViD's Rule of Usability). There's no real workaround for basic cybersecurity competence, at least at the moment.
> a well-drafted Privacy Impact Assessment
Are you saying you don't design your software systems before implementing them, nor document them before they go into production? It's the work of half an hour to reformat process documentation into a Privacy Impact Assessment report. And yes, as anyone who's worked on safety-critical infrastructure knows, process and documentation save lives. This is not burdensome.
> or a 50-page DPA
I don't think I've ever seen a DPA that long: they're usually under 10 pages, and boil down to "you are the controller, we are the processor, we're not responsible for the data, you're responsible for instructing us to fulfil any data subject requests, we won't fulfil them on our own, we won't peek at the data, here's how we're keeping the data safe". If your DPA is 50 pages long, then I'd warrant there's a bloody good reason for it to be that long. Are you saying you'd go into a complex business arrangement with a service provider without paperwork clearly setting out the expectations for each party to the contract?
(Note that Article 28 does not require the DPA to be a separate document: it's absolutely fine for it to be part of the main contract, so long as the necessary boxes are ticked. Afaik the phrase "data processing agreement" does not appear in the text of the GDPR. Splitting these contractual clauses out as a separate document is a decision made by companies for their own convenience – much like how programmers split programs up into libraries and modules.)
> The DPO isn't an engineer.
Let the DPO requisition an engineer. Running the appropriate queries against the database is a 2 minute job, so round up to half an hour. It's the way Stack Exchange did such things in their first few years of operation (admittedly, pre-GDPR, but that's besides the point). If the engineers are interrupted more than twice a week, then you can have one of them spend a couple of days throwing the tooling together to let the DPO field the requests alone.
> In healthcare, patients care that their data is secure and the service works. They aren't losing sleep over "data portability."
That's actually a major concern for anyone with complicated healthcare needs, who plans on moving to the catchment area of another practice. The amount of time wasted trying to persuade a new doctor that yes, I do need that medication, no I can't have the cheaper medication, I'm allergic — no, I do not want to "check" that I'm allergic, I nearly died the last time… no my prescription for this one needs to halve, not double, it's lower because I'm discontinuing it… all vastly simplified if they can just read up on your electronic health record, which data portability guarantees they're able to do.