Packaged Data Services: Data Protection Considerations

Introduction

Data protection is often considered the enemy of monetisation, given the perception of Data Protection Officers (DPOs) stymying innovation. This needn’t be the case as long as you consider Data Protection at the same time as designing your monetised data products, and by applying a risk-based approach during development, you are more likely to achieve a positive outcome.

GDPR is the global standard in data protection, and does not just apply to EU entities, but any entity globally dealing with EU based data subjects and where there is economic activity within the EU. Even in cases where it does not apply, it has become a benchmark for data protection globally and is emulated in a number of other jurisdictions.

This paper provides a brief overview of some of the data protection considerations arising from GDPR and gives some pointers in designing regulatory compliant data products.

Relevance to Monetised data products

One key concept that GDPR introduces is the role of data controller and data processor. Whilst a formal definition of these is outside the purpose of this paper, the former can be regarded as the party that operationally is accountable for the content of the data for its data subjects (end customers), and the latter is a party executing instructions on behalf of the controller.

We will cover these roles a bit more later in the paper, but regardless of your role you need to ensure you handle client’s data to conform with data protection regulations in all the jurisdictions you operate in.

Finally, concepts of data ethics, particularly with regards to aggregating data, application of machine learning, profiling and bias are all extremely relevant and also likely subject to regulation at some point in future. I have covered these topics in depth in previous papers.

Data Protection Overview

This is a complex subject, but irrespective of the data protection regulation in force (and there can often be more than one), in designing a monetised data product you need to consider the following five stages when it comes to the flow of data.

Not only are the rules complex, but when to apply them are too. Therefore, analysing the activity you want to perform and to whom is essential.

Risk Profile Overview

It is important to be very clear in the jurisdiction of the data subject, processor, controller and any outsourcing third parties (including infrastructure, business and technical operations), as ultimately all these will need to be factored into what is permissible, what isn’t permissible and what may be permissible in some circumstances.

Additionally, it is important to be clear on whether the service you are providing is regulated or not, and also the type of personal data being handled.

These considerations are complex, and it is important to tackle early on, by following these three stages:

The risk profile matrix will typically be one or more 2x2 grids of service vs jurisdiction, these should also be separated by type of activity (including outsourcing of business, infrastructure or IT).

Depending on the level of the risk profile, different levels of client (and in high-risk cases, regulatory) consent may be required, and also dependent on the risk profile different levels of mitigations to be adopted especially when dealing with inter-jurisdictional data transfers.

By designing these mitigations at the onset, many (but not all) data protection obstacles can be avoided early in the development process.

Processor and Controller overview

If you are providing data services to a large corporate client, it likely default position is that the client is the controller of the data and you are the processor. This is somewhat different where the client is a member of the public via an app, in which case you are likely to be a controller.

The terms of use and the contract for services must spell this out very clearly so there is no doubt.

Given the controller has more burden put upon them under GDPR, it may be tempting to this it is advantageous to be a processor. Actually, if you are trying to make money out of the data, this may not be the case, given by definition a processor has restrictions put upon them both contractually to the controller and legally by GDPR and other regulations.

In short if you are trying to make money from your client’s data you need to be careful what you are trying to do as some activity may cross the line into being a controller, which is something you cannot unilaterally decide what to do (without client consent and contractual agreement), and other activity may be plain illegal. Therefore, whilst sales can create imaginative monetisation cases for the data, you must involve both the DPO and legal teams to determine what is allowable.

Specific Data Processor restrictions

To summarise the sorts of activity which a processor can do when designing data products, the following figure shows what you can do, what you cannot do, and what you might be able to do.

To ensure your monetised data products make you money all these complexities need to be considered before committing to a specific outcome.

? Deryck Brailsford October 2022.

If all this makes sense, you really should hire me as I have made this happen in both big and small companies. I am a specialist with more than 25 years’ experience in this field. Please contact me on?[email protected]?or on +44 7710 435227.