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:
- Processes for data protection during collection, storage, transfer, etc.
- Processes for assessing risks (applicable to systems and components related to personal data)
- Organizational processes and documentation regarding access rights to the data, policies, and other bits of bureaucracy
As for the setup, it will generally look something like this:
So, your setup should follow the following steps:
- The user accesses your service via the web, for example.
- You should provide a secure channel to collect personal data (e.g. TLS on your web).
- They transfer their personal data in an encrypted format to you.
- When you receive personal data, you should continue transferring it via the secure channel (still TLS).
- You use an API to decrypt TLS and encrypt the data, or transfer it straight to your database, encrypt it there and process it via API.
Collection
Firstly, you need a system in place for the collection and storage of client data. A data entry point is usually a web form, mobile application, file upload instrument, etc. Whatever the data entry point you will need to ensure:
- Secure data transfer from the client to your app or another system, e.g. using an encrypted channel (TLS).
- Personal data doesn’t settle in your system architecture while being transported from the collection point to the storage location (e.g. in the system of logging, analyzing traffic, requests, etc.).
- The database that stores the personal data is in a different network (segmentation from other parts of your infrastructure).
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.
Processing and Storage
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:
- Store data so that it is encrypted.
- Strictly limit decryption access to select services/people.
- Log and analyze any access, audit, or other events at set intervals.
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.
Pro-Tip
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 that 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.
Data Transfer
Another thing that you should be paying attention to is 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).
Access Management
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.
System Security
Each system that you use to store personal data should adhere to security requirements for:
- Access and rights management.
- Secure authorization and authentication management.
- Management of changes to the system.
- Task management and backup.
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.
Safe Development Management
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:
- Access controls and role-based rights.
- Authorization and authentication systems.
- Event audit and monitoring.
- Version and integrity controls.
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 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.
Organizational Security
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:
- You should explicitly define and approve the list of employees who are provided access to personal data.
- All processes should be outlined and documented in set policies.
- All IT and infosec procedures should be logged, i.e. edits, commits, and search history, the addition of new employees to the access list, changes to the system or database where personal data is stored, changes to the configuration of the balancer that is responsible for points where personal data enters your systems, etc. should all be logged.
Premise Security
Here, there is nothing new. You need to ensure security where your servers are located:
- Access control should be set in an approved document.
- Monitor the area with CCTV.
- Physical access should be restricted via special key cards.
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.
Wrapping Up
With my last words, I want 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 the show do not work and will have to be shored up sooner or later.
Like this article? Check out some other explainers and insights at the intersection of security and privacy.
