In the previous two parts of this blog series, we went through the key GDPR principles, data subject rights (part 1). And part 2: controller & processor responsibilities, what is DPIA, roles & responsibilities of DPO & security breach notification policies.
In this final part of the series, we will look at the responsibilities of an IT team to help them reach GDPR compliance for their application/product. Then, I will talk about the steps that we took in our application.
Let’s jump in!
Responsibilities of an IT team
- Know where the is data stored
- This is the most important task that a controller should do for GDPR compliance. They should be able to map data flows across systems (regardless if it’s in a file system, on a cloud, database or whatever data storage mechanism they might be using).
- Be selective: work from high risk to low risk.
- The controller should be able to know where the data is stored. Is it a third-party cloud provider, a relational database or a NoSQL database?
- They should also know how old the records are and how much data they contain.
- Controllers should know what third parties possess data. This is important as only then the controller will be able to respond to the data subject rights within the stipulated time of 30 days.
- Delete unwanted data
- Start looking for duplicate copies of data in your system.
- There might be some “Just-in-case” backups.
- Delete data that is no longer required. For example, data that is older than retention policy.
- The controller should not underestimate this particular task. In today’s day & age, there are multiple systems communicating with each other via REST endpoints or other communication channels. So, it’s really complex to identify (and sort out) the impact of data deletion in 1 system.
- Work out how to respond to data subject rights
The controller should ask this question to themselves: Do we have the capability in our systems to respond to data subject rights requests within 30 days? Do you want to automate the process of getting data records of a data subject? Or do you want to provide it as a self-service where the data subject can log in to our application with his/her valid credentials and download the data concerning him or her.
GDPR does not recommend or favor any of these approaches. It’s up to the controller and their way of working to see how they want to respond to data subject rights’ requests.
- Create risk register & prioritize risk register
- Identify all places in your system where there is illegal processing of data.
- Locate the places where data is being processed after the retention period.
- Identify places where third-parties (processors) are involved in processing data.
- Find all the locations where you might be having inadequate security such as:
- Inadequate control assurance
- No pseudonymization or encryption of critical personal data
- Access control: who is accessing what?
All these things should be captured & registered somewhere so that controllers are accountable to comply with GDPR.
- Plan and remediate
This is a major task for the IT teams. They should do this based on prioritized risk (keeping an eye on the GDPR principles and data subject rights requests).
GDPR compliance in our project
Now that we have seen what are the things that a controller should do, let me share the steps we took in our project.
We are working on a telecom domain application which involves capturing a lot of customer data like their name, address, contact information, IBN etc.
It is important to do a data analysis and identify critical information that we store in our system. These are the things that should be deleted after the retention period is over (or after legitimate use of data of data subject is completed).
- After a deal was confirmed, we had a lot of emails or PDF’s with sensitive information like signatures, IBAN and other contact information. All these files were saved on our server directory. So, we had to get a list of all these files and delete them permanently.
- Because we need to do a background check before signing a deal with new customers, we had a record of their credit scores. This had to be deleted as well.
- Thirdly, there were a lot of XML’s (containing critical information) which were shared with external systems. Again, we had to delete them from our file system, database, and logs. Moreover, we needed to inform the involved third-parties and instruct them to do the same.
- Finally, we had to delete all SMS’s that were sent to customers.
The GDPR principles
All the above points were about the clean-up of customer data once the retention period is over (principle of storage limitation). But what about other GDPR principles?
Let’s take a look:
Integrity and confidentiality. Our application has a lot of personal information of data subjects. (like gender, nationality, identification number like passport number or SSN/BSN, address etc). We masked these or deleted them after the retention period.
Data minimization. We removed all irrelevant fields from our application to make sure we ONLY collect necessary data. We also deleted a lot of unwanted data which was hanging around in our systems (in a temporary table or in logs etc.).
Data privacy. To make sure that the data only can be viewed by the personnel that was granted access, we put some controls in place using pseudonymization or by password protecting different directories or files on our servers.
Some challenges we faced
These were the steps taken for GDPR compliance. Obviously, there were few challenges that we had to face.
Mapping data flow. This was the most complex task that we had to do before we know how to delete it. As we also need to think about the data that we send to processors for processing, this task should not be underestimated.
Identify critical information of data subject. This is another tedious task where we need to think a lot about the question: What is critical information? Also, we need to see where we are storing all this information.
Getting buy-in from data processors. As with all modern applications, there will be some data that is shared across third-party processors. So, we need to communicate with the data processors and make sure that if some information about a data subject is required from them, then its easily accessible. Maybe through REST endpoints or in a password protected spreadsheets. Anything is fine as long as they can access it quickly so that we can respond to data subject right within a period of 30 days.
Keeping data after the retention period. In some cases, we need to retain the data for a few days after the retention period. This was to ensure that the Business Intelligence (BI) team can create a reconciliation report. It was a bit confusing as the common notion is: Once the retention period is over, we should delete all the data concerning that data subject. But if we go through the GDPR principles carefully, it says that if a data controller has a legitimate reason to have your personal data, then they can keep it. So, in such circumstances, we can maintain data until we are done with our internal processing.
Be diligent about data. Thanks to GDPR, controllers now need to show accountability in complying with the GDPR principles. So, it’s imperative that they should be diligent about data and make sure they do their best to protect it from unauthorized/illegitimate access.
This is not an exhaustive document as its quite difficult to sum up a 99 articles document into a blog series. But I hope it helped you to understand GDPR from a developer’s standpoint.
I would love to hear how you reached GDPR compliance for your application. Please post your comments so that I can also learn a few tricks.
Do you want to learn more about Security in software development? Register for our DevSecOps engineering training!
Thank you & happy coding.!!