How to remove a User safely from database as a part of GDPR request?

How to remove a User safely from the database as a part of GDPR request?

The scenario is given – When user decided to leave your system along and requested that delete record from your database. How do you deal with it?

First of all – Think —- DELETE!!!!???? NOooooo…. Big NO. Why?? I will explain in a bit.

So, you have a database of a couple of million people and you have a concern that if everyone wants to delete their record due to any reason you will be in trouble.

So how to remove user safely and without compromising compliances.

  1. Instead of delete record obscure the requested information and leave original record as it is.

  2. The benefit to that is when you have to go through audit trail you will have all the track back and relevant to other’s information. That information still can be valuable if you are making an infographic without revealing any of personal details.

So why not delete it? If you delete a primary record from the database which related to many tables could cause system errors and many of the reports may become invalid, especially some of non-trivial.

Secondly, if you delete a record without proper provisional logs and audit could lead serious compliance issue with other ISO standards.

Now, what to obscure

  1. Name – First Name Last Name …. anything that Identifies entity.

  2. DOB – Just year or Partial

  3. Address – (partial – house number and postcode or anything)

  4. Phone Number – Partial or full

  5. Passport number — (Why do you need this in the first place. if it is a legal requirement no need to delete or obscure it.)

  6. Driving licence – Same as above.

  7. Other information — if mandatory information is already obscure and this may not able to show a person then as it is otherwise partial obscure.

How to obscure Data

For example look at following table

Field Original Data Obscure Data
Name David Halmen 01010 101010
DOB 01/01/1956 01/01/6591
Address 1234 Palm street, Coleville 0000 Palm street, Coleville
Passport G121654685 XXXXXXXXXXXX
Driving Licences —- —–

Now the question is still there what if data is not normalised and duplicated many places. Well, you have to make sure that all the information related to the GDPR are compliances and you are following the guideline given by ICO.

The solution for better information storing and providing software as service and processing data correctly.

For me I would carry out it like as given following:


Now in above picture

A client communicates through common service channel where data is encrypted using token and through SSL layer via the internet. And Common service channel will pass it to Communication Channel and decrypt, abstract and validate information and pass it to database secure channel and Software Service layer will decide which key management to use and send control to database secure channel where it again encrypted and send to the database.

Same way retrieve information will keep that way as well. Now it might look overkill at this stage but when it comes to security in mind each layer has its own authorization and authentication mechanism in place thus it abstract dependency of database and its operations to secure channel and communication channel has one job to abstract command and data and pass it to software service layer which is main heart of the multi-tenant service provider and because of key and token manager is separate part of the database we have to keep isolated apart from encrypted database.

The encrypted database keeps hashes and logs to countermeasure with key manager thus it will keep up to date with any changes in the key management and ideally it should be on the different environment but within a close system.

If you would like to get more guidance on this you can communicate through this contact form or via LinkedIn or my other website

[contact-form-7 id=”1147″ title=”Contact Me”]

Leave a Reply

Your email address will not be published. Required fields are marked *