FAQ

Simple answer is yes.

Although there is arguably the GDPR clause around legitimate interest, unless you have been keeping a record of when the Data Policies (perhaps included in your T&Cs) have been accepted then it would be difficult to provide what the individual has agreed to in terms of their data being processed. Sometimes GDPR is simply seen as an excercise of opting in all your contacts, however thats not the case, changes to the policies cover the following;

  • Changes in the definition of consent
  • Using legitimate interests as a basis for processing
  • Transparency, you have to tell people about your processing
  • Data Subkect Rights
  • Processing data on Children
  • Your recordkeeping
  • Data Protection by design and by default
  • Your relations with other organisations
  • Changes in your relationship with a data processor
  • Security
  • Breach notification
  • Data Protection impact assessment
  • Will you need a Data Protection Officer?
  • Transfer abroad
  • Fines and enforcement

Assuming your a CiviCRM user, the first action would be to enable the GDPR extension in your CiviCRM implementation.

You can find out more about the extension at CiviCRM document site

Our guidance should be used in conjunction with indpendent GDPR advice as every organisations data has been collected using different avenues and therefore will contain varying levels of non-compliance risk.

To burst the GDPR risk bubble, our guidance is that organisations take a stepped approach, identify and segment the contacts they have and tackle each set in a manner that is effective for that group.

In parallel you should be working on an effective data policy, which contacts will agree to when they update their communication preferences. With GDPR collecting opt in's without data policies is not an approach which meets the goals of the guidelines, as you would fail to communicate how the data subjects data will be used and therefore would not have a right to store the contact in the first instance.

An alternative waterall approach would be to simply email the entire database, notifying them of the impmending GDPR regulation and prompting them to update their communication preferences. You could argue this approach is the least risk of non-compliance on the other hand its also the most likely to reduce the number of contacts you'll be able to communicate with if you purely used the results for future communications as the opt in rate is expected to be very low.

The GDPR extension allows for organisations to identify contacts who are effectively dormant, i.e. have not been engaged in any form, by using activity's to exclude those who have had contact and are therefore deemed active or recent. Often an organisations database would have been migrated from another system or spreadsheets and it becomes difficult to prove the data was aquired legimately or by which channel and therefore identifying these records first is the approach we are using in this example.

As an organisation you need to determine the following;

  • Which activities you would deem as engagement, for example attending an event or making a donation. You should try exclude outward communication activities, for example bulk emails, as these do not necessarily prove engagement or recency.
  • Determine the length of time to go back i.e. 3 years
  • Identify contacts you wish to be excluded from the results for example staff, VIPs or public register contacts. Note that you should ensure invidual communication preferences are set correctly at this stage to avoid one of the identified contacts being communicated incorrectly going forward.

Once you've done this you can setup your activity selections in the GDPR Settings as explained here

Your organisation is now ready to begin communications with these contacts.

Google Authenticator is an application that implements two-step verification services using the Time-based One-time Password Algorithm (TOTP) and HMAC-based One-time Password Algorithm (HOTP).

Two Factor Authentication, also known as 2FA, two step verification or TFA (as an acronym), is an extra layer of security that is known as "multi factor authentication" that requires not only a password and username but also something that only a user has on them, i.e. a piece of information only they should know or have immediately to hand