DPO Stories #6 - Analyse This

ONCE UPON A TIME...

Our company wanted to set up a webanalytics tool. Different vendors from Gartner's golden quadrant were requested to provide information on their solution. SAP was one of them. They already delivered some other services for our company, a.o. a customer database application and a staffing database application. The SAP people played it very smart and fired up the potential users of a webanalytics tool, the marketing department and especially the data miners and analysts.

• You can capture all kinds of data with it: structured and non-structured.
• You can capture the data that is entered even if the webform has not been submitted. Amazingly useful to test and see where the users make mistakes in completing the form.
• You can upload and search data that is publicly available on your customers.
• You can install a cookie so it is possible to track the customer that has once been "hard authenticated" in the online webplatform you can identify the customer even if he is not logged in. You can give them a cross-platform experience they will never forget.

Marketers, data miners, data analysts,... they LOVE all those possibilities. WOW! And yes, they were SOLD. 

Only... in the implementation phase is the project manager confronted with the privacy impact assessment (PIA) requirement and with the actual task to set the parameters for the tool. Anyone with experience in project implementation knows that a tool that "can do it all" means a tool that has to be fed so much data and parameters and sometimes even needs customisation that the project manager's hair color slowly shifts to grey. 

The PIA quite quickly learned that: 

• keeping the tool purpose bound would be a challenge: webanalytics OK, identifying the customer even when not logged in - at least "in the grey zone", capturing data that is is a form that is not submitted - unacceptable, hoovering publicly available data for social media - only when we are sure the customer consented (is that even possible?), etc.
• the legitimate basis for this kind of processing would have to be consent of the customer completed with a fair dose of self-discipline in processing the data in the background; the then upcoming cookies legislation would also make opt-in the standard to be met; also: how to ensure no special categories of data are captured in the unstructured data?; etc.
• the company would have to be very transparant about this, especially about the fact that a customer could be identified even when not logged in;
• accountantability in the organisation had to be very clear: so single person (function) at a significantly high level as first line gatekeeper with reporting duty and escalation power to top management
• security, with the potential amount of data that would be stored, would have to be very high; so strict access management (basically a team of 5), access logs, etc.
• confidentiality, people with access respecting the purpose of the data set and not sharing it with others, would have to be ensured: a manual, training with Q&A by the DPO himself, yearly renewal of the training and evaluation of the setup; etc.
• rights of the data subject would be important: low treshold opt-out (right to object), contact line with the complaints handling department, etc.

After a few iterations the project manager was able to transfer most of the elements that came from the PIA into the project in a satisfactory way, but for the consent. How could that be well captured? The standard application at the time did not foresee in an opt-in functionality. There was an opt-out functionality. An opt-in functionality would require an extra cost to SAP of minimum 500k and additional work on the side of the company as well. 

The project manager received clear signals that management would not accept that cost. On the other hand, the project manager was really keen on getting the tool as compliant as possible so the data could be used with a fair level of comfort for the company. So back to the drawing board for the consent.

After a lot of bouncing ideas the project manager and the DPO settled for what they called an actively promoted opt-out. There is no such thing in the legislation. Only opt-in (consent) and opt-out (right to object). But this concept would need to approximate an actual opt-in so close that it could be assimilated with it. The main elements: 

• before the start the existing customers that log in get a message in the inbox of the application that is very explicit on (1) the analytics and in particular the fact that the identification to a large extent is taken along even when not logged in and (2) where to find the opt-out;
• periodic repetition (at least once per year) of that initial message, as the case may be adapted to the changed situation;
• a lot of information to be found in permanently available locations: the general privacy statement and on the page where the opt-out button can be found;
• a very low treshold opt-out, easy to find, lots of references to it, instructions to the "normal" channels (like the complaints handling department) to help requestors, etc.

Of all customers that received the active promotion for the opt-out only one customer "made it" to the complaints handling department. The accountable person did not yet feel comfortable enough to address that on his own, so the DPO helped out and called the customer. The customer complained for about 5 minutes and then the DPO got to explain the choice of the company. Very openly, it was explained how the choice came to be and that the company in fact excelled over its competitors that basically all did the same, but - due to a number of reasons - opted to keep those practices in the dark. The customer was positively surprised by such openness, even thanked the DPO, would use the opt-out and leave it at that.

A few years later the marketing department realised that even with a fair deployment of the application it did not provide what they were looking for and they chose to install google analytics (professional) to be able to compare the results. But that... is another story.

COMMENT

The lack of standard opt-in functionality is a sign that IT companies at the time did not take into account the data privacy constraints its customers had to deal with. 

• Asking single customers to pay for that to make a fit with their project is not commercial. There is an opportunity cost, but it is generally not that high as to support an extremely high premium to a single customer.  Indeed, the lack of standard opt-in required quite some organisation, planning and self-discipline which would have been avoided where to standard tool to provide an opt-in. It would also mean that controls would have to be set up to ensure that the organisational setup did not fail. But all that did not way up to an extra fee of over 500k.
• IT companies often, if not always, place the burden of compliance with regulations with their customers. That is in most cases only fair. However, in SaaS solutions and with more data privacy regulation and enforcement thereof in the (near future) it is expected that the selection of an application provider will need to be a solution provider, compliance included or at least in the parameter setting and NOT in customisation.

Privacy impact assessments are not a one off thing. They can and have to be reiterated at times. And the sooner you include them in the project stream, the more they are able to think along with the business towards reasonable solutions, acceptable by all stakeholders.

Budget constraints are real and have to be taken into account by the organsation, including by the DPO. The ideal situation where compliance is 99% certain can be very costly. So sometimes the DPO has to look at the overall picture and see what is feasible and still meets the requirements of the company and the law. In a company that wants to be compliant, there is often a solution to be found in looking at the overall picture of the end-to-end process.

Openness on the what is often seen as the "dark side" of marketing data processing (profiling etc.) does not have to turn out to be detrimental to the business. It keeps the company in check and increases the trust customers and data subjects have in the company.

THE POWER OF STORIES

(repetition of the intro of the series:) Stories are of all times, but lately organisational behaviorists and marketers have a renewed interest in them. DPOs have stories as well of their own experience or heared in there community. And they should use them to engage the organisation, at least to raise awareness, questions and/or discussions. Note that we keep some obscurity and that any reference to a name or situation you may know is likely to be based on coincidence. :-)

CALL TO ACTION

Do you have any good stories? Can you (pseudonomised) share them? (If so, please, do.)

Do you have a story on how to creatively come to a reasonable solution meeting business requirements and compliance requirements?