In my previous article introducing GDPR for developers, I looked at the regulation in broad strokes and identified the key ways that your customers' rights will need to manifest in your business. Those were:

  • Informational – You will need to be far more transparent with your customers than has been required in the past regarding how you collect and process their data and how they can exercise their rights under GDPR with your business.
  • Technical –You will need to enable these rights via application features to be efficient in delivering them. System processes, security and infrastructure will need to take account of a business’s obligations under the regulation.
  • Business Process - There will need to be business processes and people in place to respond to rights being exercised or events occurring that require a business response to meet obligations under GDPR.

Many of these rights aren’t new. They are either grandfathered in from the previous Data Protection Directive or are evolutions of those rights. The difference is that with the introduction of GDPR, they will become uniform law across the European Union. Together with the Data Protection Principles, they provide a technology-agnostic framework for the protection of personal information.

Enabling them involves putting in place the business processes to make them happen. In many cases to be able to deliver on the business’s obligations, it will be necessary to develop technical systems to realise them. Let’s look at those rights and how you may need to realise them in your applications.

Data Subject Rights under GDPR

Right to be informed (transparency of information)

Your customers should be informed of their rights and how to exercise them. This requires the business (i.e. the Data Controller) to be transparent with such information at the point that they are requesting data from their customers.

You should inform them:

  • Who is the Data Controller (usually your company) and specific contact details for a Data Protection Representative (in some cases a DPO) within the business.
  • The reason you need the personal information you are requesting and how that information will be processed.
  • Third parties that you will share their data with.
  • If the processing will involve transfers to third countries outside of the EU and the safeguards that are in place to protect their data if this will be the case.
  • The retention period for the data.
  • The existence of their rights and how to exercise them.
  • The existence of automated decision making including profiling and information about how decisions are made and the potential significance and consequences of those decisions to your customer.

Okay, but what does this mean for you as a Developer?

Well, it means that a privacy policy written to be a catch-all, full of legalese, trying to account for and generalise the reasons you collect and process data is no longer going to cut it. For each purpose you are collecting personal information across your application you need to explain, in clear and easily understood language, at the point that you collect that information, the reason you are collecting it and how that information will be used. Some of the information that can be applied across the board can remain in your general privacy policy, but what is specific to the context and purposes for which a customer is giving you their personal information (think about where you collect information – Application Forms, Contact Forms, Order Forms etc.), should be unbundled and presented to them at that point, clearly and concisely. That translates to a UX challenge and an accountability challenge.

Consent is one of many lawful bases

Consent is not the only lawful basis which you can collect and process personal information. In fact, if there is another legal basis that you can process the data under, it is preferable to do so. Examples of other lawful bases to process personal information include:

  • Contractual necessity.
  • Compliance with legal obligations.
  • It is in the vital interests of the Data Subject.
  • It is in the public interest.
  • It is in your legitimate interest (after considering Data Subject rights which may override your legitimate interests).

Consent is what you will need in cases where you do not have another lawful basis to do so. When using consent, to be accountable under GDPR, you should record your customers' consent.

Review how you collect personal information

Unbundled Contextual Consent Graphic

Contextual consent - you need to unbundle the specific purposes you are requesting their data and explain how you intend to process and use the data away from your general privacy policy.

When informing your customer of their rights, your reasons for processing etc. you are going to want to present that information in a user-friendly way, ideally, layering the information using modal dialogs or otherwise and you're going to need to take a snapshot of the terms that the user agreed to for your records to be accountable under GDPR should you be audited. The reasons for data collection and the processing that happens with the data submitted through that form may change over time, so it is important to have a record of what your customer consented to at the time they agreed to give you their data. Finally, enable the user to explicitly express their consent to the data collection using a mechanism such as a checkbox or a switch.

You can see straight away that depending on how forms are constructed within your application that this could pose a significant challenge from the outset. Perhaps you custom-build your forms in which case you can do a review of all forms that collect personal information and layer on the required UX, present the necessary information to the customer and provide them with an explicit opt-in as part of the form. You then face the challenge of recording their consent and snapshotting the agreed terms. Not to mention the process and storage considerations that follow. You may be using a form builder plugin within your application. If so, you are relying on that vendor to recognise their customers’ needs around GDPR. Ideally, the form builder should enable you to store form-specific data protection information alongside the form itself. It can then be sent as part of the form submission for further processing and enable recording of it for audit. Another option is to store the form-specific data protection terms in a single repository that gets versioned each time it's changed — storing the version identifier for the terms the customer consented to along with your consent records is a strategy that can work.

Where does the data go after it’s been collected?

This question opens a can of worms. Is it used to create a member profile on the site? Did a customer just place an order? Is it stored as part of the Web Application? Does the data get duplicated and sent elsewhere for further processing? Does it go to 3rd parties? This is where the challenge of controlling your data grows legs. You need to think about how your customers' rights are protected and enabled in relation to all of this information that you collect and store.

Are you Profiling?

If you’re collecting data on your customer (perhaps in the background on your website or from 3rd parties) that they did not personally give you, but that data gives you the ability to identify them as an individual you also need to be transparent in how you collect and intend to use that data and ensure that you have a lawful basis for doing so.

If you take one thing away from this right, it should be that you need to focus on how you can present information to your customer, clearly and transparently.  Give them unbundled, contextual consent, and then record their acceptance of that.

Right to access their data

Your customers have the right to access the data that you hold on them. Ideally, this will be through an online portal.

You already have an online portal that enables access to the data? Great, you’re all set! If not, you may want to look at providing one. Depending on the volume of requests that you get for access to that data it can quickly become a drain on business resources if you have to individually respond to them. This can also pose a problem if the data that you hold gets sent outside of the boundaries of your application and used across many different systems. It may not be trivial to expose it through a single view made available to your user.

Right to rectification of their data

You customer has the right to correct data that you hold that they believe to be incorrect. Again, depending on the volume of these requests that you get, it may be wise to provide the ability to do this in an online portal for your customer.

Right to erasure of their data

Your customer has the right to request the deletion of the data that you hold on them. This isn’t an absolute right, and I’m sure you can imagine it playing havoc with how many of your systems work if you suddenly must delete records left, right and centre. If you run an e-commerce store, your orders likely contain customer data. Deleting your previous orders would likely throw out your reporting systems and so you may need to look at developing a process for anonymising the personal information contained in orders for which you wish to maintain some form of records of after you receive a deletion request.

Your customer has the right to request removal of their personal data when:

  • The personal data is no longer necessary for the purpose it was originally collected.
  • Where the customer withdraws their consent.
  • When the customer objects to the processing and there is no other legitimate interest for the continuing of the processing.
  • The personal data was unlawfully processed.
  • The personal data needs to be removed to comply with a legal obligation.

There are some reasons which you may refuse to comply with the request. For example, your legal obligation to store certain records for government reporting purposes may override the right of immediate erasure by your customer in some scenarios, but at some point, you will need to enable it and for most businesses it will need to happen without undue delay.

If you have passed on any of your customers' personal information to third parties for processing, the deletion request will need to be passed on to them to remove the data as well.

If you want a deeper dive into the Right to be Forgotten, you can read an exploration of it by Stanford Law School.

The right to restrict processing of their data

Your customer may request that you do not process their data any further. You must be able to enable this objection. Where a customer contests the accuracy of the data you hold, you must restrict processing until you can verify the accuracy of the personal data.

The right to data portability

This is a contentious one and certainly non-trivial to implement. Your customer has the right to request an export of their data in a machine-readable format. Some may see this as an invitation to competitors to encourage customers to easily move their account from one supplier to another and in some cases, that is indeed what will happen. Each industry has (or doesn’t in many cases) its own standards for data transfer and the GDPR does not specify specific standards to use. Either way, this is a particularly burdensome feature to put in place, especially for smaller businesses. It also causes headaches because a customer’s data will likely not all be stored in a single repository. It could be siloed across data stores and services and pulling all that data together in a single export may be no small feat.

The right to object

Your customer has the right to object to the use of their data unless your legitimate interests override theirs, which in most cases it won’t. If you use their data for direct marketing reasons they need to be provided with a facility to object and notify you to stop using their data. Their ability to object and ways to do that need to be made clear to them from the point of first communication onwards.

Rights concerning automated decision making

Unless you have obtained explicit consent from your customer allowing you to process their data in a way that produces automated decisions that may have a legal or significant impact on them, you are not able to do such processing. Customers must also be able to request human intervention in the decision-making process, be able to get an explanation of the decision and to be able to challenge it.

Do your systems result in an automated decision for your customer? If you are, for example, a financial institution offering loans to customers via online application, are they able to object to the automated processing and have human intervention?

GDPR is sensitive to the increasing use of AI and automated processing occurring with people’s data. It firmly puts the power in the customers hands to object to such processing and to require organisations to provide a human step in processes that can have a significant impact on your customers.

Developers need support from all strands of the business

The GDPR accountability drive should be led from the top in your company. There should be organisational awareness that everyone needs to be rowing in the same direction to achieve what could potentially touch every area of how you do business. If many of the provisions of GDPR are not currently part of the process and culture of the organisation, it can be a significant challenge to put it in place. If the effort is not being led from the top, if for example you're a small business or start-up and the technical awareness and acceptance of the business challenge is not there among management, it can be an even greater challenge.

There can be an attitude of "let’s wait and see" among management, and the belief that the business is too small to come on the radar

It has been a long time coming and has been kicked down the road a bit since it was first proposed in January 2012 as a needed reform to the 1995 Data Protection Directive. Developers have long been bringing attention to the fundamental challenges that being accountable under it can bring to the business and its IT teams when it becomes law.

GDPR - Data Protection Principles

The Data Protection Principles that you should base your business activities on

There can be an attitude of "let’s wait and see" among management, and the belief that the business is too small to come on the radar for such stringent regulations, especially when they hear fines of the magnitude of €20 Million Euro or 4% of global turnover, "surely that can only apply to the big boys?". It’s certainly true that big organisations are likely to be made examples of. It’s also likely that to demonstrate that it’s not only they who will be held accountable, Data Protection Authorities will be conducting themed inspections across different industries starting at the other end of the scale and bringing SME’s firmly in the sights.

Bring Awareness

If you’re experiencing this head-in-the-sand scenario in your company as a developer or technical-lead, then your first step in making sure that your company is working toward accountability under GDPR is to bring awareness to the issue from a technical perspective. Illustrate the challenges the company would face on the journey from where it is now to being able to comfortably say that you are doing everything in your power to be accountable under the GDPR. A full picture of your company’s exposure is difficult to appreciate without doing a thorough mapping of your systems, data collection and data flow processes. It's likely that there are a few glaringly-obvious challenges that are good starting points for working towards compliance. These are useful to illustrate to management that standing still is not an option.

A large portion of the workload will fall to technical teams to implement the systems that support the processes to move the company towards GDPR accountability. It does not happen overnight and the sooner you start, the less pressure your teams will be under, the implementation will be more robust, and you'll have a better product as a result.

In my next post I’ll look at the technical and infrastructural measures that IT teams should consider as part of their GDPR accountability drive.

The legal bit: I am not a solicitor and as such, what I say in this post should not be taken as legal advice.

topics mentioned in this article


Alan Mac Kenna

Alan Mac Kenna

Web Development & Data Protection Specialist

More Info

About Alan Mac Kenna

I write about various topics including Content Management Systems, Data Protection, Software Development and Recruitment & HR Tech.


Latest Posts