Universal security and privacy automation
Protect data and manage risk
Analyze conversational chat data
Reduce the time and cost to comply
Self-service without friction or delay
Align data protection and business use
Tailor access controls and data privacy
Flexible, consistent, scalable
Automate actionable compliance steps
Who we integrate with
Our professional services
Power responsible use
From clinical to commercial
Optimize data tests
Open new revenue streams
Realize the potential of the cloud
Protect data from misuse
Transform your data
Opinion and industry insights
An A to Z of the industry
The podcast for data leaders
The latest compliance news and advice
Press releases, awards, and more
Staying at the cutting edge
The team behind Privitar
A thriving partner ecosystem
Our story, values, and careers
Dedicated customer assistance
Dec 03, 2020
Complying with the Right to be Forgotten doesn’t have to be a binary trade-off between preserving the privacy of individuals or maintaining data utility. By leveraging the benefits of de-identified data, it is possible to achieve both.
The Right to be Forgotten (RtbF) empowers individuals to request the deletion of data relating to them and prevent entities from processing their data under the General Data Protection Regulation (GDPR).
To show how this works in practice, imagine that I use an online travel agency for some flight and hotel bookings. Once I’ve completed my trip, I may decide that I no longer wish to be a customer and that I would like them to delete any data they hold about me. I could exercise my right to be forgotten by submitting a request to the company asking that they delete any data relating to me.
The company receives my request and checks whether the grounds for complying with it (defined in Article 17(1) of the GDPR) are met. If the grounds are met, the company must delete the data about me.
However, the company has an incentive to retain some information. For example, the fact that the bookings existed may be relevant for analytics or their auditing requirements, even if those bookings can no longer be associated with an individual. In that case, the company needs to comply with the RtbF request, while retaining some information value in their systems.
With Privitar, companies can generate de-identified data from their original data; this de-identified data could still be used for analytics after a RtbF request has been made, provided that the individual who has been “forgotten” cannot be reidentified in the de-identified dataset.
In the Privitar Data Privacy Platform™, the mappings between the original and de-identified data are stored in the Token Vault; these mappings enable users to link the de-identified data back to its original value.
The Token Vault is the only place where the relationship between the original data and de-identified data is stored. Breaking the link between the original data and de-identified data in the Token Vault (i.e. removing the token mappings) can enable de-identified data to be used for analytics while still fulfilling the RtbF needs of individuals who are included in that de-identified dataset.
This method of deleting token mappings can enable organisations to respond to an RtbF request in one of two ways:
There are some instances where deleting token mappings will not, on its own, be sufficient to meet RtbF requirements. This depends on factors including the nature of the dataset including whether it contains quasi-identifiers, the existence of other data, and who has access to the data.
Sorry, no posts matched your criteria.
Our experts are ready to answer your questions and discuss how Privitar’s security and privacy solutions can fuel your efficiency, innovation, and business growth.