Other GDPR Stuff


Data subjects may ask you to delete their personal data. For any more or less complex datamodel, this may prove to be a task between hard and impossible. If your database is used for generating customer numbers per age group throughout the years, deleting one or more customer-records is not an option.

Some may argue: “use aggregated historical data and single-row based data for statistical reporting”. But then reporting will become a lot more complex and new insights on how to interpret data cannot always be implemented on old data.

Of course Article 17.1 (a) covers not doing anything, but only one of these items (until (f)) needs to apply. Especially (b) is interesting. If a customers pulls his or her consent, he or she may also withdraw consenting the use of him or her being a customer in a specific age group and a specific region of the country for statistical purposes.

If a company wants to penetrate into the eastern regions of a country and keeps a performance indicator with balanced scorecards allowing their employees to work for this goal, presenting these may fail when customers withdraw their consent to store whereabouts.

For now, the best effort may be to implement erasure as an act to make pseudonymisation permanent and non-reversible. If a pseudonymised record cannot be used to identify a person, it may count as being erased.

Implemented wisely, it's a bit more complex. One may have to keep some kind of consent-map available in every datamodel, listing all consent-items per customer. This information then is used in a retention-policy which retires (i.e. erases) data automatically based on need, law and, this is new: consent. Retiring data may create new records; aggregates or dummy-persons for keeping reports valid.

A datamodel for consent, combined with data subjects is worth a study and a model implementation.


The easiest part of the GDPR is reporting personal data to a customer. However, there are various things you can do very wrong here:

  • you may send out the personal data of the wrong person
  • you may leak important marketing information
  • you will leak an indirect view on your datamodel

The first item will have terrible consequences, the other items are great for your competitors. Take care!

High Availability

I don't know why this is in the GDPR, but article 32 makes high availability mandatory. This includes implementing procedures for testing fail-over and restores. If you are running a service where data is allowed to be lost, you cannot be GDPR-compliant.

The only reason for this article being in is that it is needed in order to be able to successfully prosecute non-compliancy with other articles.

About this title

The first four or five titles were written in some kind of rage after visiting the Big Data Expo, Utrecht 2017. This particular title was written in February 2018. I was excited about all the technical stuff I could do with PostgreSQL, hence I forgot about the other articles in the GDPR, 17, 20 and 32 to be precise.