Legislation such as GDPR represents a significant challenge for every company that has to comply with it. Usually, they are perceived (at least at the beginning, sometimes forever) as being a stupid, unnecessary, bureaucratic evil that will cost the company a noticeable amount of money. However, there's always the other side of the coin—the same legislation can also be perceived as a business opportunity.
Every product manager dealing with GDPR (or in general with any new legislation affecting their business) will eventually face the same decision: implement the minimum requirements dictated by the legislation or go the extra mile and implement certain support for your customers affected by the new data protection rules.
In today's blog post, I want to show you how we evaluated the impact of GDPR on our product portfolio and explain what was behind our decision to deliver certain GDPR-oriented features in our products. But first, it's very important to realize how big an impact the legislation has had on your product.
Similar Products, Different Situations
It's hard to imagine a product that doesn't have to deal with GDPR. If nothing else, you're at least maintaining your user or customer account data, which can be, without question, considered personal data. What is going to differ is the impact the given legislation will have on your product. What's more, the legislation might have a different impact on different products from your portfolio. Actually, that was our case in Kentico as well, and I want to show you how the situation differed in our case. But first, let me give you a bit of context.
In Kentico, we're helping people to tell their stories by making it easier for them to produce content in one of our content management systems. We have an on-premise solution called Kentico EMS and another product called Kentico Cloud that is offered as software as a service. Now, both are essentially quite similar products, so what's the big deal?
Well, the first difference is in the functionality. While both products focus on content, Kentico EMS over the years of its existence evolved into an all-in-one solution that also includes digital marketing and e-commerce functionality. As you can imagine, this functionality wouldn't work without entities such as visitors or customers that hold all the information required for the extra functionality to work. And as you probably guessed correctly, this means that EMS is processing a lot of personal data and, therefore, GDPR will have a large impact on customers using this solution. On the other hand, customer choosing Kentico Cloud won't have that many marketing capabilities at their disposal, even though there is still the personalization functionality included in the product that requires the collection of data about website visitors. Therefore, even these customers will have to deal with GDPR, but to much lesser extent.
Roles and Responsibilities
The second difference is the roles of the involved parties and their responsibilities defined by the legislation. Each company has a different commercial model and relationship with their customers. You can choose to focus on B2B or B2C customers, or you can operate in both of these markets. You can sell to your customers directly, leverage your partner network, or operate as a self-service. Moreover, your customers might not even be the end users of your products. For example, we sell our CMS to digital agencies who then use it to build websites for their end clients. And that's just a few examples that struck me first. But the relationship you have with your clients is very important to consider when analyzing the impact on the product as it defines your role in the relationship from a legislation perspective.
GDPR requires three main roles. Firstly, there's Data Controller, a natural or legal person, public authority, agency or any other body which alone or jointly with others determines the purposes and means of the processing of personal data; where the purposes and means of processing are determined. Secondly, there's the Data Processor who represents a natural or legal person, public authority, agency or any other body which processes personal data on behalf of the Data Controller. Finally, we have the Data subject that represents the natural person whose personal data or sets of personal data are being processed.
Now, how might these roles roles differ for different products? Let's use Kentico EMS and Cloud as an example again.
Roles and Kentico EMS
Now with EMS the roles are as follows:
- A website built on Kentico EMS is going to be accessed by visitors, effectively making them Data Subjects
- The website is owned by an end-client who decides what data is going to be tracked and how (meaning the end-client determines the purpose and means of the processing ) making the end-client the Data Controller
- The website is developed and continuously updated by the development agency (data is accessed and processed by a partner) which means that the development agency is, therefore, the Data Processor
- The website is hosted in the data center owned and managed by the development agency making it the Data Processor
- And finally, Kentico as the provider of the solution has no formal role in the relationship defined by the legislation
As you can guess from the description above, GDPR puts a lot of pressure on the agency that is implementing the website for the end-client. Especially as the implementing agency will have to help their clients, who are using the extensive marketing and e-shop functionality, to be compliant. On the other hand, Kentico as the solution provider is in a really good situation as the legislation has no impact on us in this case.
Roles and Kentico Cloud
Now, let's analyze the same relationship, but this time for Kentico Cloud:
- A website built on Kentico Cloud is accessed by visitors, again making them Data Subjects
- A website built on Kentico Cloud is owned by an end-client who decides what data is going to be tracked and how and that makes them the Data Controller
- The website is developed and continuously updated by the development agency therefore making it a Data Processor
- The website is hosted in a data center owned by the development agency (the agency is the Data Processor) or a third party (the hosting provider is the Data Processor)
- Kentico Cloud a is service provided to end-clients as a SaaS hosted in third-party data centers making Kentico the Data Processor
- And, moreover, Kentico runs the service and determines what personal data, why and how is going to be processed for the purposes of internal subscription management making Kentico the Data Controller
Now in this case, the situation is slightly different as Kentico shares Data Controller and Data Processor roles together with the development agency. Therefore, Kentico will have new responsibilities as it now has a fully-fledged role in this legal relationship and will have to follow the rules of the legislation.
Please note that the two mentioned examples are not the only settings of the relationship we have with our clients and partners. There are many others that shape the final responsibilities (e.g., a different hosting provider, another technology partner, etc.). Therefore, you should always try to identify all the involved parties and their mutual connections.
I hope this example helped you understand how important is to understand your role as a vendor in the relationship with your clients and what impact a new legislation such as GDPR can have on this relationship. Understanding the roles is really crucial for the audit that is then going to help you identify the minimal requirements you will have to meet in order to be compliant with the legislation. And that's why I stressed the importance of the analysis and the audit in my previous article—after all, the identification of involved parties and their roles that I showed you is one of the outcomes of the analysis.
Mimicking the Customer
The audit and analysis undeniably play a very important role in the whole "becoming GDPR compliant" project, but they're only going to help you to identify and address the minimal requirements. Lawyers and experts will never tell you: "Oh by the way, you should implement feature X and support for Y so your customers have an easier life when dealing with the same legislation." There's only one thing that is going to help you with the identification of all the needs and struggles your customer are going to face—you will need to mimic your customer.
So how we did it in Kentico? A pre-built sample website comes as part of our product offering. We call it Dancing Goat and it represents a small roasting company selling coffee and accessories to local cafes. The website is easily deployed, updated between releases, and usually serves as a demonstration of CMS functionality. This time we took it, created a fictional corporate background, and hired a legal expert to mock up an audit for this company.
First of all, we spent several hours with the lawyers going through interviews explaining the business of Dancing Goat. We explained how the marketing department of our fictional company worked (roles, processes, etc.) and how they leverage our product. It was a vital part of the whole process as the consulting company needed to understand the usual business scenarios of our end-clients and especially how the product works. Without the context is impossible for them to conduct following parts of the audit or provide you with any informed recommendations.
Second, we had to map the Dancing goat marketing processes, identify all personal data and describe how they're processed. Needless to say that this task represented quite a challenge and showed us the importance of a well documented solution. Moreover, it helped to realize the amount of personal data that we have in our product, especially the data that we didn't expect to be influenced by the GDPR legislation.
Finally, based on the process and data mapping, the auditing company created a gap analysis where they identified legitimate interests of the company and processes that require certain action (collecting consent, reducing amount of collected data, etc.), so the affected personal data processed within them are handled lawfully. Once we knew the recommendations, we tried to implement them on the website to understand how easy or difficult it's going to be for the customer. This step provided us with insights what parts of the product are lacking and could be improved and I believe it was the most valuable part of the whole audit.
Please note that we were focusing on the "marketing department" of our virtual Danging Goat company because this is most likely going to be the department that's responsible for the website and promotion. The real audit your company might undergo will certainly be more complex, significantly longer and not as straightforward as the one I described (which we had to undergo as well). Nonetheless, the mock audit can help you understand better your customers and what they will have to do in order to become compliant. It is definitely an experience worth having.
Deciding the Scope
Now that we had the two perspectives - what we must implement as the company to be compliant and what our customers are going to need - we could decide what we will implement. In the end, we decided to implement several features and product improvements:
- we focused heavily on the documentation- as I mentioned before, thanks to the impersonating the customer we realized how important it is to have quality documentation available
- we decided to implement Consent management in our on-premise product - as the product handles a lot of personal data, managing consents will be crucial for our customers
- we have support for Data subject rights in both of our products - we provided our partners with options to trigger the Right to access and the Right to be forgotten in our product easily without any custom implementation
- we implemented support for multiple datacenters in Kentico Cloud, so our customer can choose whether they want to host their project data within EU borders or not
To be completely honest with you, there were also other factors that were driving the finial decision to invest into implementation such as situation on the market or remaining time to release, but I believe that the two factors that we discussed today were the most influential.
I hope this article showed you how can be legislations such as GDPR perceived not only as (un)necessary evil but also as business opportunities. In the next and final article of this series I am going to share with you our mistakes and lessons that we learned on this huge project. Until then let me know in the comments what is your experience with choosing the scope for GDPR or other legislation projects. Did you go with the MVP or you went the extra mile?