-
What do you mean 'only store collections of identifiers'? Where is the actual data then? It needs to be linked up for use, which would mean it could be linked by someone compromising the database while at rest, no?
Under GDPR, if I were selling you something, I might have a shopping cart that said:
profileID: 47714
items: 1 x clydesdale wheelsetNothing in there is personally identifiable, so it needs less protection.
But somewhere, there would be a system that could take profileID and translate that into "hippy".
That system/service, that does the translating is the one that would be audited, alerted, protected, secure.
And then you may imagine that actually a billing system starts to look ridiculous as it's just a collection of identifiers. Something like:
profileID: 47714
addressID: 98756
emailID: 98436
paymentMethodID: 54217A system like that is fine under GDPR, and can be compromised. It tells you nothing.
The difference ultimately is the answer to the question, "Where are the fortress boundaries?".
In older systems, the fortress boundary was the network perimeter. Once compromised, everything was accessible.
In new systems, the fortress boundary will be a specific single-purpose datastore/service, and compromising a network perimeter gets you nothing at all. You'd need to compromise every internal fortress too.
The new standard with GDPR in mind, is to isolate all information from each other, allocate each an identifier, and only store collections of identifiers, and then use systems of record to resolve bringing the information together at a time when you need to (whilst auditing access to each system of record, and alerting on abnormal access patterns, etc).
GDPR is pretty interesting, read about it here: https://iapp.org/news/a/top-10-operational-impacts-of-the-gdpr-part-8-pseudonymization/