How to craft GDPR compliant software

Six leading principles to follow for GDPR compliance.

In our former post, we saw that General Data Protection Regulation (GDPR) is a world in itself. To help you find your way, here are 6 leading principles you should consider to develop GDPR compliant software.

1. Obtain informed and active consent to be GDPR compliant

If your software collects personal data from users, you will have to consider integrating the following elements. The data may be given directly by the user or automatically collected from other software or an enterprise directory:

Display complete and transparent data policy

• What data are requested and why they are needed
• Specific purpose of processing
• Detailed means of processing: collection, use, sharing, storage, etc.
• User’s rights regarding its data, among which the right to withdraw consent at any time

Make sure that information is clear and can be easily accessed

• Pop ups at first connection with privacy notice
• Visible menu dedicated to data privacy and protection policy

Obtain user’s active consent and keep track

• Separate consent request from terms of use, as it must be given voluntary
• Consent must be detailed and broken into different options to enable users to make specific choices
• Forget pre-checked boxes, as consent must be active
• Keep proof of all elements of the consent. What information was given to the users, to what did they give their consent, how and when was the consent granted?

2. Minimize data

According to GDPR, “Personal data” covers huge and various sets of data. Email address (private or professional), home address, photo, physical data, posts on social media, online identifiers such as IP addresses, cookies, log files, etc. We had also seen earlier, that “innocent” data can become personal data, if their combination allows identifying a specific natural person.

That’s why one of your golden rules ought to restrict to data that is absolutely necessary. You meet user and system requirements, by asking these questions:

• What data do you absolutely need to collect?
• How long do you need to store the data?

In practice, this might mean adapting some software-building practices, like logging, user registration or data import from Software Development Kits, external software components (libraries…) or even enterprise directories. You can also introduce some periodical alerts or automated processes for data review and deletion of useless data.

3. Protect data for GDPR compliance

When we talk about data protection and avoiding data leakage, we immediately think of:

• Regular and safe backups
• Access controls

But another best way to protect personal data is to hide them.

Depending on the risk and sensitivity of data managed in your software, you may activate one or a combination of the following techniques:

4. Ensure data accuracy

The accuracy of personal data is integral to data protection. GDPR defines that “every reasonable step must be taken” to erase or rectify data that is inaccurate or incomplete”. It’s clearly linked to users control rights, that we will detail in the next paragraph.

Of course, as a developer, you’re not in the frontline regarding data accuracy. Most of recommended practices are linked to organizational processes. We won’t even start the discussion on what is an “inaccurate” or “incomplete” data. This would take us too far from the point.

However, you can help ensure data accuracy at the software development level. Providing data subjects effective means to update their personal data, such as:

• Integrating automated checks of data accuracy
  For example, you can generate periodically predefined alerts at users’ connection. Ask them to check if the personal data stored in your software are still up to date.

• Providing users easy access to modify all data concerning them
  That means that generally, all the fields should be editable via the GUI. This includes data you may have collected from other sources. This could happen if users accessed with a login from another software or social network, giving you the ability to retrieve their name, address, etc.
  

5. Enable user’s control

After being fully informed and having granted active consent to the processing of their data for a limited and specific use, every EU citizen must be able to keep control of all their personal information.

Remember: Apart from derogations linked to national defence, public security or other important objectives of general public interest, personal data belong to individuals, not to data processors or data controllers 😉

Generally, GDPR grants 1 month to the data controller to comply with users’ requests regarding the exercise of the following rights, meaning that time is allowed for manual processing. However, things will be much simpler and end users will be grateful (including administrators of IT services for professional software), if you follow the “Privacy by Design” practices when designing any new piece of software.

That’s why you should consider providing mechanisms to allow users to verify, correct, export, move, and erase their data as easily as possible.

GDPR rights for user data

• Right to rectification
  As stated before, this has something to do with data accuracy presented above.

• Right to erasure (‘right to be forgotten’)
  Users have the right to have their data erased without undue delay. Therefore, your software or database should include tools allowing to quickly identify and erase personal data as needed.
  This is not a trivial task: finding every record related to one person may be quite difficult.
  Even professional software is concerned. Many modern tools offer collaborative features, giving users the ability to exchange and write comments. In the same way, when an employee leaves the company, you should ensure that depending on the situation, all their personal tracks can either be easily deleted, pseudonymized or anonymized in your software.

• Right to restriction/object of processing
  Restriction to processing may be either temporary or permanent depending on the reasons of the user’s request.
  Right to object can concern your software, if it uses algorithms and machine-learning to automate individual decision-making and profiling. Individuals have a right to object to such processing of their data. E.g. to refuse decisions based solely on automated individual decision-making, (including profiling) if this can affect their legal rights or have a negative impact on them. For example, e-recruiting practices based solely on automated decision-making processes without any human involvement.

• Right to data portability
  Users must retain the ability to transfer their personal data from one software or service provider to another. Thus, you should also consider providing appropriate data export features. That means that you are sure to export all the data related to the requesting user, but no more. And especially no data belonging to other users!

• Right to be notified of data breaches
  Even if all precautions were taken to protect data and prevent data breaches, this is a risk you must be prepared for. Who didn’t hear about leaks of sensitive data from Twitter or LinkedIn, for example?

GDPR requires any company experiencing a data breach to inform at the earliest the local Data Protection Authorities (DPAs) and all users who might be affected. At development level, this means that you should consider building a well-designed process to detect and report breaches.

6. Document data protection and data processing

According to GDPR, not only should you think of how to protect personal data and comply with users’ rights. But you should also be able to demonstrate compliance with GDPR by documenting your data protection measures and data processing activities.

Data protection measures

This means that you will have to document your design and software development. Norwegian Data Protection Authority (DPA) gives some examples. These will allow the final data controller to “document and demonstrate how the requirements of the data protection regulation have been implemented”.

• Documentation demonstrating that the software has been developed using a methodology that ensures data protection by design and information security (SSDLC – Secure Software Development Life Cycle)
• Reports from security audits
• Vulnerability scanning
• Security tests such as penetration testing
• Reports on exercising data breach management

Data processing

Even if your software only processes basic data such as log data, IP addresses or users ID, there may be hidden personal data, which leads to compliance with several documentation obligations as a data processor. Indeed, the way you are building your software will impact the associated documentation requested by GDPR compliance rules on several points:

• Categories of personal data which are collected
• Type of users concerned (data subjects and recipients)
• Purpose of processing
• Expected length of conservation
• Categories of processing: collection, use, sharing, storage…
• Protection measures: access controls, encryption, access controls, pseudonymization…
• How you keep tracks, among which users consents or data breaches

Why your efforts for GDPR compliance will pay off

The same goes for GDPR compliance as for software quality. The earliest you integrate it in your development process, the easiest it will be to comply with! Moreover, GDPR offers you a great opportunity from many perspectives:

• You will increase users trust, which is a good point for your reputation and customer relationship
• Even if GDPR applies “only” for EU citizens and EU companies, data privacy is a global concern. And many countries in the world engaged similar mechanisms to enforce users’ rights and protection regarding personal data. Let’s just mention California Consumer Privacy Act (CCPA) that came into force on January 1, 2020.

Finally, by giving you good reasons to put more emphasis on security and privacy, GDPR will help you earn points regarding your compliance with principle 3.12 of the Software code of Ethics 😊

References and further reading

• GDPR  legal text
• ICO: Guide to the General Data Protection Regulation (GDPR)
• Norwegian Data Protection Authority: Guidelines for Software development with Data Protection by Design and by Default
• CNIL: Guide RGPD du développeur
• InfoQ: What Should Software Engineers Know about GDPR?
• Further blog posts:
  • Software Code of Ethics: Respect the privacy of your users
  • Hippocratic Oath for developers: The software engineering code of ethics