As the basis for the main requirements for data protection we will consider the EU GDPR as the most pervasive and influential legislation in this area. In this article we will skip the legal and organizational parts of the regulation which you can read elsewhere and jump right in to explain what technical measures you can implement to get compliant.
If you have a compliance check scheduled you will need to have the following in place:
As for they set up it will generally look something like this:
So, your setup should follow the following steps:
Firstly, you need a system in place for the collection and storage of client data. The data entry point is usually a web form, mobile application, file upload instrument, etc. Whatever the data entry point you will need to ensure:
In general: all network components which take part in the process should also be set up to keep the data secure: closed access to portals that don’t need it, traffic addressation configured, etc.
You could store the data in a single database, just as you could store it across several as part of a distributed system. Depending on what the volume is and the type of data you are storing there are different safeguards that need to be put in place, but, in general, databases should:
The main task is to ensure the security of the place where you store data and always understand to whom or where data is transferred (i.e. who has access to the data).
The most obvious solution here is to define a personal access matrix in the database (point 2 in the schema above) for services and apps. You should explicitly define access rights to the data for one or another request.
It’s a good idea to define the types of data requests with fixed reasons for the requests and the data sets involved. You should also create a list of authorized systems which can access the data.
Defining the access matrix is made difficult if the personal data is requested by systems such as analytical ones, which save part or a copy of the data in their own database (point 3 in the schema above). Similarly, things can get complicated if data can be requested by systems (System 1) and then passed on (to System 2). In this case, you will need a personal data search mechanism built into your infrastructure to track personal data traffic. Such systems allow you to monitor personal data in transit and provide you with analytics into usage and access.
Another thing that you should be paying attention to are the channels through which personal data is transferred. The data should be transferred only through secure channels (2 in the schema above) and/or encrypted (e.g. encrypted while in transit — 1 in the schema above).
This is the same as the majority of processes related to access; here there aren’t any special procedures. Access to the systems where data is stored/processed/etc. should be defined for specific services, applications, and employees. More often than not, this is realized by employing access rights to the systems which contain personal data or tabularly within the database.
Any access to the personal data and actions performed with it should be monitored and logged.
Each system that you use to store personal data should adhere to security requirements for:
For a list of procedures, you can choose from ISO 27001, ITGC, COBIT, NIST, etc. taking into account the risks you defined for your information assets.
The legislation and standards give special attention to the security of how you develop systems where you will store personal data (SDLC). At the design stage, you will need to build in mechanisms such as:
Any changes in your systems should undergo safety checks: you need to be sure that the changes made won’t compromise your security perimeter, run the risk of a data breach, or give access to the personal data to those that shouldn’t have it. I mean, it’s pretty obvious that your software engineers shouldn’t have access to personal data in your systems.
Although I said at the start of this explainer that the organizational bits and how to comply with them can be read elsewhere, it is still worth mentioning a few key moments:
Here there is nothing new. You need to ensure security where your servers are located:
Many companies now build their infrastructure in the cloud, but you should nevertheless be sure that your service provides and/or infrastructure is SOC and ISO certified.
With my last words I want you to leave you with the main point of this explainer: when you are preparing for a personal data compliance audit, you don’t have to prepare any differently from any other IT or infosec audit set out in the main standards because they follow the GDPR. What you do need to do is use common sense: align how much you are spending on data security with the value of the data itself, and always have security plans in place. Practice shows that processes for show do not work and will have to be shored up sooner or later.