GDPR for Product Owners and Developers

GDPR has been a big boom for us all. While browsing the Internet, we can easily find a lot of info about what GDPR is, who and what it applies to, and what requirements we should meet as companies in order to comply with the regulation. But for many of us in the Internet industry, there’s still the question of HOW we should actually apply it to our product.

At Woodpecker, we did some research, tried to find the best solutions to implement, and then finally we came up with the things that should be done to make our product GDPR–friendly. I wanted to share a few tips which may inspire you to introduce some changes to your product or service.

Who is this article for?

Before we start, let’s establish who can benefit from this article. The tips I present within this blog post can pique the interest of SaaS product owners, developers, Data Protection Officers, or any app owners, IT enthusiasts or the crowd interested in how GDPR influences their work or practices.

Below, you’ll find some key aspects of data safety for GDPR-compliant products and services.

If you have a vague idea about GDPR, start with this article:

GDPR Basics for Email Senders >>

or download our GDPR ebook >>

Data Deletion Procedure

If you create, design, or maintain any product or service, you should definitely think about how you can exercise the right to delete data defined in GDPR. I’m fully aware of the fact that deleting data may be extremely troublesome for some data models.

Nevertheless, you should be aware that the difficulty of data deletion may not be a good enough excuse anymore. In case of most databases, deleting data should be feasible so long as you implement a system to switch from, for example, a user ID into null, to keep things in order.

In many apps, the problem with data protection stems from the need to track events and activities within the application, and at the same time, not being allowed to store personal data due to data safety requirements.

At Woodpecker, we spent a lot of time thinking about this issue.

We decided to use a hash for our new GDPR-features which enable data encryption. Once our prospect is encrypted, we keep a piece of information, which may be comparable to a token – it does not involve any personal data, but at the same time, our statistics remain intact and clear.

This concerns your users as well. The described feature of Woodpecker was prepared for the safety of our users – simply to enable them being GDPR compliant while using our app.

As you can probably imagine by now, there is not just one good solution. But no matter what solution you choose for your system, what you should do is to think about enabling data deletion in your app. And once you do this, you should come up with a way of substituting personal data in your system to keep the reports on activities and events working.

But what about your sub-processors and third parties you’re integrated with?

If you push data through API, don’t forget about providing a data deletion end-point to enable an API request for data deletion. Where may it be applicable? For example, if you use any CRM which stores your customers’ data and you wish to have a coherent system for data management, including data deletion.

Data access limitation

If you’re an admin, this part would be especially interesting for you.

The question is: how do you limit data access at your company? You probably know that the times when all the people can access everything are over. If you’re responsible for data safety or data flow at your company, you should be able to assign data access roles and permissions to your co-workers.

How to do that? Check if the tools, software, and all the in-house solutions you use allow a “limit access” feature, which would enable you to draw a map of who can access what and why.

This is also a good starting point for DPOs who are willing to take good care of data safety in their companies. And now struggle because they don’t know where to start.

Again, if it is important to you as a software user – it is probably significant to your users too. If you provide any tool or service that enables personal data processing, you should definitely consider developing a functionality that limits an access to various kinds of data.

Age limitation

You are probably aware of special age restrictions (be especially careful if you use profiling!). As a professional business owner or developer you need to ask yourself a question – do you wish to grant access to minors or do you wish to restrict it?

When you decide to allow them an access to your app, you potentially need to collect the consent from parents once any profiling activity is concerned.

Of course, the choice is yours. Plan ahead and be aware of the consequences. You can ask your users to provide their age upon registration. But if you decide to skip that step, definitely make sure you restrict the age of your users. And communicate it in your Terms of Service or Terms of Acceptable Usage of your service/product.

Consent forms

There were numerous discussions about how consent forms should look like under GDPR. The main thing to remember – the signupee should express their will to a single, well-defined and unambiguous thing, be it a subscription, gated content download, or registration for something.

Also, a key rule here: there should be no pre-checked checkboxes, no long-winded sentences or multiple consent collection for 5 activities with one tick. There should be a separate checkbox for each activity to allow your user to explicitly choose what they sign up for.

Also, if you’re not certain if the previously collected consents were collected in accordance with GDPR, collect them again.

Data Export

People managing data may need to export the data of data subjects from the systems they use. That is why an ‘Export’ button may be extremely useful to have.

For instance, at Woodpecker, we enable our users to export multiple data in a CSV form. That allows them, among many things, to comply with an obligation to return data (most often with the data deletion which follows data return).

Most likely, if the data you store is simple enough, you can enable data export in a CSV or XML form. The ‘Export’ button would probably be a relief for your support team. Instead of querying through the database, the user is able to get a requested report or export data with just one click.

What about cookies?

Without unnecessary oversimplifications, of course, we may imagine a situation which links cookies to personal data and data processing. Nevertheless, before losing your hair over it, bear in mind one thing. Cookies are mostly associated with the ePrivacy Regulation, not with GDPR.

No settled version of the ePrivacy Regulation has been issued after the GDPR. But if you wish to take a look at the draft, feel free to check it out here.

To sum up

GDPR may bring a lot of changes to your company, within the system or the software.

You should be aware of its key requirements and realize that “it is impossible” is not always a good excuse. BUT it is not always bad, either. A lot depends on your individual case.

Any time you make a decision about data storage (like the period for which your store data should be longer or shorter, for instance), you should be able to justify your decision. Stating that you store data for 10 years just because you can is no longer legitimate (to be completely honest, it actually never was).

Just try to keep your system, your company, and your subsequent product designs in line with the best practices of data management. And remember to always have a rationale to back up the steps you take and the decisions you make.