How to make your Ruby on Rails application GDPR compliant
Learn, wich changes we will make to your application - whether it is Ruby on Rails, NodeJS, Elixir or any other platform
Every user has the right to be deleted
That sounds easy, but it can be more than difficult for e.g. the following reasons
1. Your Ruby on Rails application uses "soft delete"
Soft delete is a very common practice and we would bet, that your ruby on rails application is using it.
It basically means, your data does not get deleted, but instead flagged as "deleted".
This is being done - of course - to keep access to user data, which is what GDPR wants to avoid.
But it is also done to avoid data corruption, which can be hard to predict and a large problem for your application.
How to recognize it
Search in your application for the word "paranoid", which is a common library for Ruby on Rails. Or see if the database schema contains a column "deled_at". If you find this, you can be sure, that you are using soft delete
2. Data can be hold after deletion
User data will not be only stored in the user table of your database. It is probably cached, copied, referenced and displayed in other places.
Also it has been sent to external services.
How to recognize it
Create a full map of your data flow and eliminate all external services from storing user data.
3. Data corrupts on deletion
In a Ruby on Rails application data corrupts for example, when on a screen with comments under a blog post, the user avatar of the commenter is being shown. If that user now is suddently deleted, this will raise an error.
If that happens on a visibile screen, you are lucky, because you will realize it. But it can also happen in invisible background jobs and far in the future.
How to recognize it
The only way to prevent data corruption is to consistently develop a stable data model, write tests and follow development best practices.
If we have to make your rails application GDPR compliant, we will review code, ensure the test coverage and write specific tests that ensure, deleting a user will not cause problems
Need a user deletion checkup?
An overview over your datastructure has to be present
We have to include your internal datastructure and your external services.
This is recommended as the first step of making your application GDPR compliant
1. Show the structure of your database
There are several tools to inspect your database structure in a ruby on rails application. Rails erd and Railroady are common ones.
While this can be helpful, it can be also simply confusing. So a manual step has to be provided.
If your database involves sharding, multiple databases or cloud storage, for e.g. message queuing or key value stores, the manual review is very important.
2. Give a meaningful overview
Experts can help you to give a meaningful overview about which data is stored where and how to access it.
We help you with an in-depth analysis of your application.
Data migration has to be possible
Data migration essentially means: Your user has the right, to move to another platform.
That sounds legit, but it should be currently almost impossible in most cases.
The reason is, that a database represents a very individual structure, developed for your application to function in the way how it functions.
Define standards
To become GDPR compliant, you will have to define a generic export standard for your application data. Most importantly you will have to decide, what to include. That has to be decided in a careful review and should involve legal counseling.
Create a machine readable format
Next you have to choose the format for your export and make sure it follows what is widely accepted as machine readable.
We can provide you with a standard for that, but also for this step you should involve legal counseling.