GDPR Support - BloomReach Experience - Open Source CMS

This article covers a Hippo CMS version 11. There's an updated version available that covers our most recent release.

19-10-2017

GDPR Support

This feature is available since Hippo CMS 11.2.3.

As of the 25th of May 2018, organizations in non-compliance of the new General Data Protection Regulation (GDPR) will face heavy fines. 
The General Data Protection Regulation (GDPR) is set to replace the Data Protection Directive 95/46/EC.

Hippo has taken already at this moment all required steps to provide all tools to the Relevance Stack that are needed to assist our clients with their GDPR compliance efforts.

As of this writing, the Relevance Module GDPR Support is available in BloomReach Experience Manager 12.0.1 and BloomReach Experience Manager 11.2.3.

Being Compliant with GDPR in a Nutshell

To be compliant with GDPR, organizations

  1. Have to be able to serve all personal data the organization has about a visitor if the visitor requests this
  2. Have to be able to forget about a visitor if they wish so
  3. Require a proper consent of the visitor about the personal data they keep about that visitor
  4. Have to understand the risks associated of not being compliant to the GDPR

Relevance Module GDPR Support

The Relevance Module addresses GDPR support by making use of pseudonymization, something (GDPR) encourages. At Top 10 operational impacts of the GDPR: Part - 8 Pseudonymization, you can read a concise formulation about it, the most relevant part is:

The GDPR introduces a new concept in European data protection law – “pseudonymization” – for a process rendering data neither anonymous nor directly identifying. Pseudonymization is the separation of data from direct identifiers so that linkage to an identity is not possible without additional information that is held separately. Pseudonymization, therefore, may significantly reduce the risks associated with data processing, while also maintaining the data’s utility. For this reason, the GDPR creates incentives for controllers to pseudonymize the data that they collect. Although pseudonymous data is not exempt from the Regulation altogether, the GDPR relaxes several requirements on controllers that use the technique."

The way BloomReach Experience Manager supports pseudonymization is as follows:

The data we store about a visitor does by default not contain any information that can re-identify the visitor without a unique random UUID only known by the visitor and stored at the visitor's client (typically the browser of the visitor)

Through this pseudonymization approach and the existing cookie consent support, you as customer are assisted in your GDPR compliance effort as follows:

  1. Implement the cookie consent if you did not already do this and possibly add information to the visitor of your website / application what kind of data you will use from the visitor and to which purpose
  2. Add the Public Relevance REST Endpoint to
    • Expose the Personal Data you have about the visitor on request of the visitor
    • Add the option for the visitor to be forgotten

Apart from the above new tools (REST endpoint), since version 12.0.1 and 11.2.3 , BloomReach Experience Manager does not store the IP address of the visitor anymore in the data we track, because an IP address could be used to re-identify a visitor to the data. What we now store in the data are the city, country and a longitude / latitude point with a granularity equal to city, meaning in no way usable for re-identifying a visitor.  

Since BloomReach Experience Manager 12.0.1 and 11.2.3, the IP address of a visitor is not stored anymore in the data we collect. 

Own Responsibility

Although BloomReach Experience Manager provides all the tools to assist you in your GDPR compliance effort, we cannot rule out that you implement something that is not GDPR compliant. So, there also lies a responsibility with the developers who implement the website. More explicity: we provide an extensible delivery and Relevance framework. This means for example that you can implement your own Custom Collectors, which collect data as well (which gets stored along with the data our default Collectors collect). Now assume that you add three custom collectors which in some way collect from visitors the 5-digit ZIP, gender and date of birth. The study Simple Demographics Often Identify People Uniquely revealed that with these three data characteristics, 87% of the US citizens were uniquely identifiable. Hence, if with custom collectors you collect these three characteristics, the data can be re-identified to a visitor, and you are not GDPR compliant anymore. Since these custom collectors are in the realm of the end project, we can only advice and stress the importance that you realize what data you gather and whether the data you gather does not result in a re-identifiable data set. 

Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?