Background Information on GDPR
What is GDPR
GDPR stands for General Data Protection Regulation (Regulation (EU) 2016/679) and at its most basic, it specifies how personal data should be lawfully processed (including how it’s collected, used, protected or interacted with in general). It’s intended to strengthen data protection for *all people whose personal information fall within its scope of application, putting personal data control back into their hands.
Where does it apply
The GDPR can apply where:
- An entity’s base of operations is in the EU (this applies whether the processing takes place in the EU or not);
- An entity not established in the EU offers goods or services (even if the offer is for free) to people in the EU. The entity can be government agencies, private/ public companies, individuals and non-profits;
- An entity is not established in the EU but it monitors the behaviour of people who are in the EU, provided that such behaviour takes place in the EU.
A common misconception is that only EU users are covered by the protections of the GDPR, however the protections of the GDPR also extend to users outside the EU if the data controller is EU based. Therefore, if you are an EU-based data controller you must, and by default, apply GDPR standards to ALL your users.
So, how does the GDPR govern cookies?
Well, the short answer is that it doesn’t — cookie usage and it’s related requirements are not governed by the GDPR, they are instead governed by the ePrivacy Directive (or Cookie Law).
Do I need to list the name of each cookie (including third-party cookies) used on our website or app?
No, the cookie law does not require that you list and name individual cookies. However, you are required to clearly state their categories and purpose. This decision by the legislative authority is likely deliberate as to require this would mean that individual website/app owners would have to constantly monitor every single third-party cookie, looking for changes that are outside of their control. This would be both unreasonable and likely unhelpful to the average user. You can read more about this here →
Must I provide the mechanism for users to manage their cookies preferences (including withdrawal of consent) directly on my website or app?
No, the cookie law does not require that you provide users with the means to toggle cookie preferences directly on your site/app, only that you visibly provide the option for obtaining informed, active consent, provide a means for the withdrawal of consent and guarantee via prior blocking that no tracking is performed before consent is obtained. This means the opt-out mechanism does not have to be hosted directly by you. In most cases under member state law, browser settings are considered to be an acceptable means of managing and withdrawing consent. You can read more about the requirements here →
Do I need to keep records of consent to cookies for each user?
The Cookie Law does not require that records of consent be kept but instead indicates that you should be able to prove that consent occurred — even if that consent has been withdrawn. The simple way to do this would be to use a cookie solution that employs a prior blocking mechanism as under such circumstances, cookie installing scripts will only be run after consent is attained. In this way, the very fact that scripts were run may be used as sufficient proof of consent. You can read more about the requirements here →
The first step is to sign up for iubenda, which you can do using this link and receive a 10% discount should you decide to upgrade. Generally, they offer free services for upto 25k page views. However, for analytics (in order to view consents given, opt outs etc) you will need to buy a plan for upto 300k page views.
The main benefits of using iubenda
- Super fast cookie banner loading with prior blocking of scripts with minimum disruption to ads after consent is given.
The next step is to implement Consent and Cookie solutions. The Cookie Solution will show a banner when a visitors comes to your site, and with the option of Prior blocking and asynchronous re-activation it can block most common scripts, such as
- Facebook widgets
- Twitter widgets
- Google+ widgets
- Google AdSense
- YouTube widgets
- AddThis widgets
- ShareThis widgets
And re-activate these scripts when the consent is received along with this you also need and should implement Consent Solution which records the user Consent. The other scripts for which there isn’t an automatic block yet – and that install cookies that require blocking prior to user consent – should be “wrapped” using these comments:
For example a conversion pixel for AdWords would be handled this way:
/* <![CDATA[ */
var google_conversion_id =CONVERSION_ID;
var google_conversion_label = “CONVERSION-LABEL”;
var google_custom_params = window.google_tag_params;
var google_remarketing_only = true;
/* ]]> */
<img height=“1” width=“1” style=“border–style:none;“ alt=“” src=“//googleads.g.doubleclick.net/pagead/viewthroughconversion/1030205862/?value=0&guid=ON&script=0”/>
If however there are parts of HTML / IMG / IFRAME, you’ll need to take these steps:
<img src=” width=”300” height=”150“>
For WordPress posts (as opposed to the above template level as for example footer.php) there are shortcodes available:
In the event of continued browsing by the user, the latter’s cookie use preference will be set to “yes” thereby removing the banner and releasing the cookies. Moreover, banners and blocking codes will not be delivered on the user’s subsequent visits since consent is registered as granted (these preferences will update at each visit).
Finally the Consent, which in order to be recorded requires you to place the Consent Code given by iubenda in the Header section of your WordPress which you can easily do through the theme’s header option.
Let us know if you have any questions.