Skip to content
Data Management  •  GDPR  •  Marketing Technology

Fostering Trust in Customer Relationships – A Privacy First Approach

Based on recent developments within a rapidly activating Privacy field, without building the privacy mechanisms across European companies in innovative and business enabling ways, we will lose the ability to respond to accelerating competition within Retail coming from both East and West, and within other industries through start-up disruptors where advanced use of data is already in-built in the products itself.


Too Often Legal is Blocking Full Use of Marketing & Customer Data

The area of data-driven marketing and especially the rapidly evolving ad tech ecosystem isn’t an easy area to understand thoroughly for either marketer, business leaders, or legal practitioners. So no wonder that going into an uncomfortable zone isn’t something that human behaviour intuitively drives when planning and implementing a new platform, application, or data processing activity. You push the hard questions to a point where they turn to be formulated asking for permission to launch or go into production. Too many times the answer is no and significant changes need to be made to slow down your original planned schedule. Working this way the legal department and overall culture regarding privacy-related compliance questions turn out to be rather conservative and risk-averse.


“Not starting with privacy as an embedded part of process design, you most probably trigger a negative atmosphere toward privacy and legislation leading to decreased competitiveness over time.”


Therefore we, at Avaus, have taken the approach to use a Privacy First Approach to build competitive edge and agility into our client organisations. This is practically done using privacy by design methodologies across the cross-competence organisation from day 1.  

To going into client and partner discussions with a Privacy First Approach has, first of all, raised many questions and I’m even more convinced that this approach is valuable. It’s becoming clearer that Data Protection Authorities are following the compliance of collecting & activating marketing data as required by the GDPR, whereas the latest iteration of the e-Privacy directive might point to other interpretations. Not to mention that the invalidation of the EU-US Privacy Shield will not make things easier in the coming fall. When looking into many Nordic companies architectural drawings during the past months, the question always arises where is the legal basis for any data processing defined or consents stored in an operational format?  


Privacy by Design Methodologies in Practice

Privacy by Design methodologies are nothing new and recently invented, but still rather rarely used in practice. The IAPP organisation has done great work at formulating the seven founding principles of privacy by design. I will walk you through them briefly providing concrete examples of how to use them to design processes around data-driven marketing in practice. For a more detailed description, you can find a link to the official formulation above.  


1. Proactivity: The approach, whether you are proactive or reactive in terms of privacy-related questions, is the biggest difference between how companies mostly work as a default state compared to being privacy first. It needs a change in behaviour across the organisation, but could be triggered by one lawyer who has a natural interest in data and tech by starting to involve her right from the beginning at the point of getting an idea for a new concept. I have a personal experience of working very closely with one lawyer for 5 years, where the first 6 months we all over again repeated what a cookie is, but in the end, that lawyer had gained more insight into data & tech than many digital Managers or Directors I know. 


“As an organisation or leader, this is behaviour that you can easily encourage or even enforce.”


2. Privacy as default setting: Purpose for data collection, limitation and minimisation of collection and retention rules obeying are the very basic requirements derived from European Data Protection legislation. Although collecting, storing and processing vast amounts of data has become financially a trivial question from a technical perspective, I argue that from an organisational resourcing perspective it isn’t trivial. The more you try to collect data, the more complex your data sets tend to evolve, which in turn means more resourcing costs and maintenance.


These days it’s tempting to collect and store every piece of information that is possible with the thought it may be needed at some point. The growing trend of data lakes is one evidence of this trend. By limiting your data collection to being precisely purpose-driven you do a favour both to be explicit with use case definition in the beginning whilst starting data collection, but it perfectly serves your compliance targets too. More data doesn’t lead to smarter data, I would claim just the opposite. The amount of data you are trying to collect often also reflects the level of agility, the more you are trying to collect the less agile you are and the speed of development may slow down. 


3. Privacy embedded into the design: I believe this is the most powerful component to turn privacy into an enabler when understanding opportunities provided by technology and utilising them in innovative ways. It could be even called fine art to balance between respecting users privacy, but exploiting the possibilities that the latest technologies provide to serve business targets and use cases. To give a few examples:


      • Packaging of data and controlling the usage of it via an access layer is a powerful mechanism to ensure that you have first of all organised your data based on different purposes of use, legal grounds and ways of combining data when processing it. Not to build too much bureaucracy, but this is one way to both standardise how data is used in terms of efficiency and building compliance risk mitigation activities at the same time.
      • Although you may have legal grounds based on a legitimate interest to collect certain data points, access to that data on the raw data level can be highly restricted for the purpose and specific user groups that it is intended for. At the same time, the same data can be used for example, on an aggregate level for another purpose not revealing any individuals’ data subject personality. A good privacy practices require full transparency of these processing activities, a subject discussed separately as bullet number 5. 
      • Whilst processing data sets that may contain sensitive personal data or reveal a third-party identity, automated detection mechanisms based on machine learning can be trained to extract those from a privacy perspective challenging data points from the data set before ending as part of data to be analysed. These kinds of automation processes are still hard and time-consuming to develop and therefore you need a good business case and most probably scale for both training data sets and business upside perspectives. 
      • If your system architecture is handling Personally Identifiable data, I would advise from day zero to use pseudonymised identifiers instead of  plain text understandable identifiers to avoid data breaches and increase overall it-security across systems communicating with each other as a standard way across your architecture. Also, Public Cloud technology vendors start to have alike native support for handling PII-data like De-identification and re-identification of PII in large-scale datasets using Cloud DLP or Dynamic data masking .


4. Full functionality: As defined by IAPP it stands at least for me with the remark of positive-sum instead of zero-sum, exactly as the explanation of balancing both user privacy and business interests in ways that lead to full functionality without compromising any parties interests. When even Privacy activists are stating you shouldn’t compromise the functionality over Privacy, this should set your bar of ambition level when working using Privacy by design methodologies. 


5. End-to-end security: Both privacy and security should be in-built into your processes instead of being an afterthought. Addressing these early on, is both easier and also more cost-effective. It might make sense to combine certain privacy and security related processes since many requirements might impact both privacy and security. In the age where processes are moving at accelerating speed into the cloud, security is becoming more important but, on the other hand, once you are fully operating in the cloud, security will be easier to handle too.


Unfortunately looking at research data, European large companies are in the very early days moving from on-premise into cloud environments. Likewise, with legal, it makes sense to involve it-security specialists or if you have a specific department for it-security in the very beginning of starting any initiative. It’s rather straightforward to think about access control, pseudonymisation, encryption, two-factor authentication, user groups roles. I strongly recommend building a review process and governance together with your IT or an external it-security vendor like Nixu.


6. Transparency: As a non-legal practitioner, it is more natural for me to take the end-users’ perspective into the question of transparency and therefore don’t interpret my words in terms of legal advice. A good example is reviewing how companies are writing their privacy and cookie policies. At the other end of the spectrum are examples that are done following word by word legal advice on how the legislation is written, but maybe non-understandable for a normal consumer. At the other extreme, there are examples of non-compliant versions looking at legal requirements, but easily understandable for the consumers on average.


Personally, I would like to be a customer for a service provider that helps me to increase my level of understanding and builds trust in the brand. At the same time, ad tech players do not make it easy for a consumer to understand how their data is handled. The Norwegian independent research institute Forbrukerrådet tried to lighten share flow within the ad tech ecosystem and published an in-depth analysis out-of-control that you can download via the previous link. After reading even the introduction of this report, not an easy balancing act at all!


Another view on privacy is that privacy and trust are intertwined and cannot be separated. Explicit consent requests can be seen as a question of transparency and trust. If your privacy and cookie policies are transparent, easy for the customer to understand and if the customer trusts you and that giving the consent will provide better service, then most customers will give their consent. On the other hand, even a hint of distrust easily means that the consent is withheld. Lack of trust related to how your customer data is handled is also not a good basis for your business so it’s not only about regulations and compliance.


7. Respect for customer data and privacy: A former colleague formulated the validation on whether to implement a use case or not, that could he be standing in front of the media if something would fail? A very practical validation whether you are doing something in the boundaries of respecting customer privacy. For myself, this defines the respect for customer data and privacy already widely enough.


As you can see living up to these principles isn’t as hard as it may sound. Actually, they may ensure everyday life working with data or data products is less painful in terms of seeing Privacy Regulation as a burden. 


The Concept of a Privacy Framework as a Business Enabler Explained

To live up to the principles and make daily operations smooth, modern marketers should have a clearly defined Privacy Framework in place. Next, I will walk you through what is meant by this concept. 


In my view, a Privacy Framework is a defined set of rules when it comes to collecting, manipulating and building data-assets or use cases consisting of especially personal data regulated by GDPR, including online behaviour data. The set of rules should be transparently documented, openly available and continuously updated as changes evolve in these processes. Depending on the level of seriousness, you may need to go to very detailed definitions, like based on which selection within a consent panel is a specific tag triggered on a website. On an overall level, a Privacy Framework acts as your manuscript to tell what can be done and what not to do.


Within the Privacy topic, many complex concepts easily get mixed up like Data Privacy Impact Assessment, Legitimate Interest Assessment, Data Protection Agreement etc. A Privacy Framework is nothing derived by legislation, it’s rather each company’s documentation making it transparent on the boundaries of the playing field ensuring that the management has taken appropriate measures to define and instruct the organisation on how to act. Most probably the Privacy Framework reflects also highly the company culture. 


One essential outcome of a Privacy Framework definition initiative is a mutual understanding within the organisation of attitude and tolerance towards risk. The guiding principles in a well-managed company are set by top management directly or indirectly. This is setting the cultural foundation towards privacy, related risks and mitigative actions. The obvious public appearance of the Privacy Framework towards Customers are terms & conditions, privacy notices, cookie notices and other privacy-related content where you explain how their data is used. Being a customer of a company provides for tech-savvy users also to observe what happens technically under the surface by using services just with simple browser plug-ins or reading actual code on the fly. An excellent opportunity to benchmark competitors or other industries since most of the Privacy practices are visible to anybody.


Lastly not to forget and I’m starting to repeat myself on purpose, the existence of a Privacy Framework can be validated only through iterative and constantly evolving proper documentation. Unfortunately, I’ve witnessed DPIA processes being organised as totally separate processes from actual development work, whereas if the documentation in the first place would be organised systematically, Data Protection Officers would be very satisfied with always up to date DPIAs coming together with a marginal amount of extra effort. 


Decision Making and Governance Should Always be Owned by the Business

This may not come as a huge surprise, but having a formal governance model in place around data processing practices is key for a Privacy First Approach. I am confident as of this date to state that the majority of the Nordic larger companies do not have yet a proper governance in place. This being a wide topic in itself, I would like to raise only the most important points to consider. First of all, it is the most central perspective in a Privacy First Approach to balance business opportunities and potential compliance risks.


For balancing, there needs to be a clear decision process in  place where final decisions are done within the business, not legal departments. For this to function in everyday business, top management must clearly understand both the upsides and potential risks or consequences of the chosen Privacy Framework principles. It is the Top Management who is carrying risks within the Privacy field, therefore it should be on their agenda to organise appropriate processes to meet their requirements to lead Privacy as an enabler and even competitive advantage in the smartest companies. 


The Five Questions to be Addressed by Top Management

Based on a vast amount of discussions and interviews among Nordic companies, I have identified some hard questions to tackle in environments, not to undermine them at all, which are extremely complex. 


1. Form a comprehensive and holistic view where and how the customer or personal data is processed having an end-to-end full understanding of the process flow. I believe there are two main reasons for a lack of that view: overall complexity in architectures where tools & technologies form layers on top of each other and secondly technology providers not making it easy to trace full data process flows. 

2. Taking tough decisions on which legal grounds to base different customer-facing activities and where to draw the line between legitimate interest and requirement for consent. Additionally, the whole consent collection isn’t easy either since you can do it in as many ways as there are consent collectors. To stand out with these challenges in a way that produces good customer experience typically requires a strong business driver with enough mandate and ambition. 

3. One very common mistake that is easy to fall in, mixing DPIAs end-to-end data processing flows understanding and descriptions with tools and technologies. As part of good governance, these two should be separated. It’s another perspective to evaluate whether a tool fulfils compliance and security demands, that is to document data flows for DPIA purposes. 

4. Sometimes I’m wondering whether Top Management of large corporations have a full understanding of the risk landscape that they are dealing with when it comes to Privacy related questions. Their responsibility is not to understand all the complex details, but there should be somebody within the organisation that is trusted and able to explain the risk landscape in plain language, not hiding all the information behind thick .ppt decks building trustworthiness.  As a CEO, I would invest in that kind of trusted advisor. 

5. As the AGILE way of working becomes a norm with fully or semi-autonomous Squads and Tribes, a Privacy First Approach usually isn’t first in their mind unless an Agile coach is having a specific interest in the area. Being an enthusiastic believer in the AGILE way of working, I see a lot of challenges in how to combine control privacy practices with total autonomy. I haven’t yet seen any outstanding solutions for this challenge across the Nordics, so if you are aware of one, please advise me on this one! 


*Views and opinions presented in this blog post are from the author and don’t represent any legal advice provided by Avaus Marketing Innovations. 

Do you need some help from us?

There is no formula to define your Privacy Framework, but we at Avaus are happy to assist you in getting started, listing all the topics in detail to be covered and sharing our experiences across industries. 





Möchtest du lieber auf Deutsch weiterlesen? Kein Problem, du kannst auch weiterhin auf der englischen Hauptseite stöbern. Wähle unten einfach deine Präferenz: