Understanding GDPR the IT Way: Helping Your IT Teams Reach Compliance
Understanding GDPR the IT Way: Helping Your IT Teams Reach Compliance
Learn more about GDPR and how your IT teams can reach compliance.
Join the DZone community and get the full member experience.Join For Free
In the previous parts of this blog series, we went through key GDPR principles, data subject rights, controller and processor responsibilities, DPIA, roles of DPO, and security breach notification policies.
In this final part of the series, we will look at the responsibilities of IT teams to help reach GDPR compliance for their applications. Then, I will talk about the steps that we took in our projects.
Let’s jump in!
Responsibilities of an IT Team
Know Where Data Is Stored
- This is the most important task 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, delete data that is older than retention policy.
- The controller should not underestimate this particular task. In today's day and 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 one system.
Work Out How to Respond to Data Subject Rights
The controller should ask the 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 valid credentials and download the data concerning them?
GDPR does not recommend 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 and Prioritize the 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 and 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 that 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 was a lot of XML’s (containing critical information) that 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, and identification numbers (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 collected necessary data. We also deleted a lot of unwanted data that was hanging around in our systems in a temporary table or log.
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 knew 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 the 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 it's quite difficult to sum up a 99-article 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 experiences in the comments below.
Thank you, and happy coding!
Published at DZone with permission of Saahas Kulkarni . See the original article here.
Opinions expressed by DZone contributors are their own.