Yeah, but isn't it possible to trivially and inadvertently combine a bunch of systems S1 ... Sn which are all respecting the GDPR into a new system which doesn't?
We will see, new regulation is coming after GDPR and I bet they will plug the missing holes there. There was a cookie law that everyone circumvented. Now the same people are complaining about GDPR. The next round is going to put even more restrictions, and the regulation is going to be blamed. But the ones to be blamed are the ones who abuse it.
I'm not sure what you mean by "holes". It seems like it's a fundamental and intended feature of the GDPR that you can't achieve compliance-by-default. You have to explicitly audit every interaction between every system you have, to ensure that either no personal information is present or the interaction complies with GDPR standards.
"...you have to explicitly audit every interaction between every system..."
But would you though? If you're a large co. you'd have a configuration management system where you just pull the specs/data rather than do an audit. If you're a small co. you'd know already, and if not you'd just go look. Right?
My experience is that anyone complaining about the amount of work GDPR is causing is a. not compliant anyway (and knows it) and/or b. has terrible or no IT governance.
Not right; you can't just review the specs of each system. It's very easy to accidentally combine compliant systems in a way that isn't compliant.
Just to pick one example I've seen in practice, system A might have an integration bug causing system B to periodically emit error logs, containing data which system A knows is personal but system B does not.
The law applies to business entities so it will go and cover every piece of infrastructure they run retroactively.
Imagine having a dev with contributions and commits in a dozen projects calling github to exercise his newfound right of removing all personal identifiable information from the system.
