I have customers that are asking "Do we really need this kind of data".
GDPR and California et al. turned data privacy from a technical-moral issue into a legal one.
And healthy companies have a robust, empowered legal department to keep them on the right side of the law.
When Technical Architect says "We shouldn't do this," few listen. When General Counsel says "We can't do this," things change.
“Did we do a PIA?”
“Is this a data leak and should we contact their privacy officer?”
These are common questions now. GDPR changed a lot of things. The basic idea that you'd just send and receive any data you have that seems useful from a technical standpoint to third parties and see what you would actually end up using is gone. Step one is as you say: “do we really need this kind of data?”
It may cost some money, but not that much by far. The reality is that in the long term, you'd save some as well by virtue of having clearer, cleaner and simpler processes.
We are a large bank, most of our processes are decades old and are an impossible mess. For reference, we have a total of around 5000 systems running in the bank... Till GDPR and also some post-2008 regulation, I guess the strategy was to mostly accept the mess we're in (it's basically an absolutely extreme version of technical and organizational debt), with some targeted initiatives to make some areas slightly cleaner. Now, GDPR would require a major redoing of a lot of stuff, most of which is not really redoable - who wants to touch critical code written in COBOL, which is powering the significant parts of economies of a couple of European countries? I suspect most of the world's top20 banks are like that. In this realm, full GDPR compliance (for example, the right to be forgotten, when the data is copied willy-nilly across 5000 apps, with no one knowing exactly where and how the data flows) is a fantasy that could only be enforced by multibillion fines.
It's essentially similar problem to global warming - till recently, all of bank's depratments were solving problems locally, but now a new threat (global warming/GDPR legislation) requires global coordination, which is extremely costly given that the bank was basically not designed for it.
1. Business and IT in big banks are both extremely complex. Business just because of regulations making everything difficult and because the business people have had centuries of time to come up with complicated schemes on how to make money and/or serve customers in a competitive way. IT because paying off tech debt is not something that banks do for the most part.
2. IT in banks is often old and undocumented, making deep modifications very hard and risky.
3. Big banks are parts of the country's (or, in case of biggest banks, world's) critical infrastructure. Hence, they're REALLY risk averse. I.e. if Google Ad words goes down, the the only impact is that people's browsers around the world start running faster without all the ads... If the bank's transactional system goes down (or worse, transfers money where it shouldn't go), then the whole social order is at risk.
There are other industries that are similar - are also old, complex and critical - like for example the utilities, but unlike banks they don't make money off of people's private data like the banks do, so they don't transfer customer's details back and forth between their systems - so the GDPR impact is much lesser.
All the mobile apps that implement tracking & analytics SDK do not comply unless they request explicit consent.
You can start there. The GDPR's spirit is great but the entities tasked with enforcing it are absolutely incompetent.
I think most corps by now realize that and are willing to live with the risk rather than lose a lot of data and introduce a lot of processes.
A nice idea, but no one will care that much.
You have no idea who they have approached, nor what they have asked [= insisted] for.
And to be clear, because of the CLOUD Act, this reaches all EU citizens on US owned platforms.