Software code of ethics: Tips to craft GDPR compliant software

This post follows on from the previous one “Software code of ethics: Respect the privacy of your users”. Let’s continue our exploration of personal data protection rules and how to develop 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.

Six leading principles to to craft GDPR compliant software

1. Obtain informed and active consent

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 the GDPR, “Personal data” covers a huge and various set 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 to identify 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

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:

Data encryption

Data encryption generally consists in converting clear text into a hashed code using a key.

Data pseudonymization

This consists in replacing the directly identifying data (surname, first name, etc.) of a data set by indirectly identifying data (alias, sequential number, etc.). Pseudonymization operation is reversible: if this can affect data security, it also allows to comply with the obligation to restore the availability and access to personal data in the event of a physical or technical incident.

Data anonymization

The objective is to alter personal data in such a way that a data subject can no longer be identified directly or indirectly. As this transformation is meant to be irreversible, it allows to exploit, share and store data without invading the privacy of individuals. On the other hand, this radical choice is not suitable for all situations, as this process aims to eliminate any possibility of re-identification.

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 comply with several documentation obligations as a data processor. Indeed, the way you are building your software will impact the associated documentation requested by GDPR 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 will pay off

The same goes for GDPR 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.
Worldwide data privacy regulations. Image source: CNIL

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

Share:

Share on linkedin
Share on twitter
Share on whatsapp

2 thoughts on “Software code of ethics: Tips to craft GDPR compliant software”

  1. Helene, this article is a great recap about Data Privacy needs and GDPR demands, “cooked & served” to properly appeal Software Development and IT folks, Who will hardly read the 261 pages text, nor Legal folks are normally able to translate legalese text into a software engineering addressable matter.
    Anyhow, let provide a contribution to the article from Legal perspective: as reported “Even if GDPR applies “only” for EU citizens and EU companies,..” it is partially misleading: GDPR applies in any case of personal data processing for EU Citizens personal or even processing of non-EU (nationality perspective) citizen Who are formally resident (even for job matters) in EU. Also reporting that” only EU Companies” are subject to GDPR is partially correct, any company having subsidiary in EU if data is shared and any Company in general if process Data Subject’s under GDPR. As most Software IT systems are using a B2C by XaaS model (any App on any Store) this is a must to have, unless you won’t manage to opt-out or not distribute your software to Individuals whose GDPR applies.. (and yes, great advise about CCPA who mimes the good of GDPR). Moreover the sentence about Privacy Shield not being anymore a valid guarantee further intensied the matter.
    https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-business-and-organisations/application-regulation/who-does-data-protection-law-apply_en

    Reply
    • Hello A.I.,
      Thanks for your interesting and detailed precisions. I tried to keep it simple but you’re perfectly right, the scope of GDPR is very large indeed and has ramifications that extend well beyond EU.

      Reply

Leave a Comment

Related Posts

A single source of truth - source code

A single source of truth

Software projects produce lots of artifacts over time, obviously the source code, but also requirement and design docs, test cases, bug reports, CI scripts, installation

The safe & secure software factory

The Safe & Secure Software Factory (SSSF) merges the principles of DevOps, Safety Criticality, Cyber Security and Industrial Manufacturing. SSSF enables you to create a

Software quality a winning team

Software quality: Winning as a team

We have exposed a nice framework in previous posts: raw data produce metrics and indicators, and a rating model evaluates quality for each project component.

Hey there!

Subscribe and get an email every time we’ve got a new quality piece on here.