Introduction
When I became the owner of the GDPR compliance program for Veeva Network in the beginning of 2017, I met with our legal team and several customers to go through all the data subject rights (like the “right of access” and the “right of rectification”) as well as the general principles (like the “storage limitation” principle and the “data minimization” principle), in order to assess how we can address these requirements in the application.
But since then, no other requirement has been so intensively discussed as the famous “right to be forgotten” ( also called the “right to erasure”). By far, this requirement has caught the most attention of our customers and has arguably caused the most headaches. I would estimate that more than 95% of all my data privacy discussions with customers are centered around this requirement. And by the way, this topic does not only come up when discussing GDPR compliance; other data privacy regulations;for example, the CCPA, have comparable requirements.
For this reason, I want to focus only on the “right to be forgotten” in this blog while intentionally ignoring all the other GDPR compliance requirements. But this does not mean, of course, that Veeva Network doesn’t provide functionality to address other GDPR requirements as well. If you would like to learn more about how Veeva Network can help you with the various other GDPR requirements, I highly encourage you to check out Data protection and privacy for GDPR in the online help.
Disclaimer
Before we proceed, please keep in mind that I am a product manager and not a lawyer or legal adviser. You should not rely on any information from this blog as legal advice. This blog is only based on my personal experience of talking to our legal team and various customers over the last four years, and it just represents my personal understanding of the GDPR. For any guidelines on how to comply with GDPR, you should always rely on legal advice from the legal counsel of your organization.
In my personal experience, the GDPR and especially the “right to be forgotten” is often interpreted quite differently, sometimes even contradictory, depending on who you talk to. Over the last four years, I have talked to numerous data privacy officers, and while there are some commonalities for sure, there are often major differences in how organizations interpret and implement the “right to be forgotten”.
I am saying this because, in my experience, there is just not a single approach that everyone agrees on and follows. Instead, our application is designed to provide some flexibility to cater the various nuances and differences that customers require. In the end, a customer organization needs to feel comfortable with the specific process that is implemented so everyone in the organization is on the safe side and follows the guidelines.
Defining the Use Cases
When discussing the “right to be forgotten” with customers, the term “opt-out” is often thrown in the mix. And in addition to that, most customers I talk to also subscribe to Veeva OpenData for their customer master data, which means that Veeva OpenData and the customer share the role of the data controller. That often blurs the discussion a little, and in the beginning, creates some confusion about who opts out from where and what to do when. Therefore, I start every discussion with a clear-cut definition of the use cases that are in question. After we are all clear on the different use cases, we can talk about the options that you have for addressing each use case.
Use Case 1: HCP opts out from OpenData
In the first use case, the HCP “opts out” from Veeva OpenData. This means that the HCP uses their “right to be forgotten” under the GDPR against Veeva OpenData. Basically this means that the HCP denies Veeva OpenData the right to store and process their personal data. But the HCP might still be perfectly fine with the fact that your organization stores and processes their personal data. So, for this use case 1, let’s assume that the HCP only opts out from OpenData but not from your organization. This means that you need to take appropriate measures to continue the engagement with the HCP despite the fact that the HCP data is no longer provided to you from OpenData.
If you are an OpenData customer, I recommend you to continue with part 2 of this blog as it outlines the options that you have as a Veeva Network customer to deal with this use case. If you are not an OpenData customer, you can skip part 2 and continue with part 3 immediately.
Use Case 2: HCP opts out from your organization
In the second use case, the HCP “opts out” from your organisation (not from Veeva OpenData). This means that the HCP uses their “right to be forgotten” against your organisation. Or in other words, the HCP lets your organisation know that they disagree with you storing and processing their personal data.
As an organisation, you have 30 days to respond to this request and remove all personal data of the HCP from your system(unless there are any other legal reasons that require you to keep the data). Now the request to “remove the data” can be fulfilled in various ways, and as I mentioned in the introduction, a lot depends on how your data privacy officer reads the regulation. In part 2 of this blog, I will deep-dive into the out-of-the-box functionality that Veeva Network provides you to manage this “right to be forgotten” request from the HCP.
Use Case 3: HCP opts out from OpenData and your organization
The third use case describes a situation where the HCP “opts out” from Veeva OpenData as well as your organization. In this use case, the HCP is neither okay with the fact that Veeva OpenData stores and processes their personal data, nor are they okay with the fact that your organization does the same.
I will not go into the details of this use case since it is basically a combination of use case 1 and 2. If the HCP uses their “right to be forgotten” against Veeva OpenData and against your organization, then the OpenData team follows their SOP as outlined in part 2 of this blog, and you follow the process that you have implemented based on the functionality described in part 3 of this blog.