1. Home
  2. Blogs
  3. Blogs

GDPR and CiviCRM

Published
2018-02-04 15:24
Written by
parvez - member of the CiviCRM community - view blog guidelines

Our new extension aims to enable charities/organisations to manage their supporters in a GDPR compliant manner. GDPR in itself does not introduce many new requirements however it does introduce a number of new obligations on organisations that hold and use data about individuals.

It’s important to understand that simply moving to an opt in process and regarding all existing contacts as being opted out overnight is probably not what is best for your organisation.  There are many factors to consider before determining whether to base your marketing contacts on an opt in . For example a membership organisation is likely to be well within its rights to base member communications on the organisation’s ‘legitimate interests’ unless the member explicitly opts out. You may also be able to import contacts from third party fundraising systems, where they have already stated that they are happy to be contacted by the charity they are fundraising for. The overall aim of this extension is to help organisations navigate the journey to GDPR compliance without compromising their presence with and income from their existing supporters.

Under GDPR, therefore, you need to be able to record whether your contacts have given consent to receive marketing.  If so, you must be able to show who consented, when they consented, how the consent was given, and exactly what the consent is for (including for which communications channel – post, email or phone, for example).

If you have not asked them to provide consent, your marketing would be based on ‘legitimate interests’.  In this case you must record any contact from them asking not to receive marketing, or specifying which marketing they do not want to receive.  You should also be able to show that your legitimate interests are not outweighed by their interests.  If people don’t respond to your communications over a period of time, the longer this goes on, the harder it might be to argue that you still have a legitimate interest in contacting them.

More details about GDPR and CiviCRM can be found at https://vedaconsulting.co.uk/GDPR

The current version of this extension does the following;

  • Allow you to record the data protection officer for your organisation

  • A new tab 'GDPR' in contact summary will display group subscription log for the contact

  • Custom search 'Search Group Subscription by Date Range' which can be access from GDPR Dashboard

  • Access list of contacts who have not had any activity for a set period of days from GDPR Dashboard

  • Ability to force acceptance of data policy/terms and conditions when a contact logs in and recording this as an activity against the contact with a copy of the terms and conditions agreed to. This is currently Drupal specific.

  • The right to be forgotten, allowing users of CivicRM to easily anonymise a contact record, hiding any person details but keeping the financial and other history. The action also exists as an API and therefore can be bolted into other processes.

Future releases will include

  • User friendly communication preferences, moving to explicitly worded opt in mechanisms.

  • Communication preference to include medium per group. Currently CiviCRM supports include or exclude from a group but it does not allow for the selection of the communication medium that should be used for example happy to receive email newsletters but please don’t send me any other emails.

  • Recording audit information when a contact is exported

  • Allowing all exports to be produced with passwords if produced with the MS Excel Extension.

 

Filed under
CiviCRM

Comments

HI Parvez,

Thanks for sharing this. The GDPR is a real challenge for lots of organisations. It's good that the CiviCRM community including Veda are thinking up ways we can support its requirements.

I think one of the biggest challenges witih GDPR is around recording an audit trail of consent, and doing so on a per-channel and per-purpose basis. As I understand it consent needs to be

  • explicitly opted in to. (specifically, linking to a download of T&Cs is not ok, and privacy statements must be publicly available - a succinct summary needs to be given at the point of submitting data)
  • it cannot be bundled along with a 'service' (e.g. signing a petition/buying something/making a donation) - so it can't be a required field or an omitted field that assumes consent is given by submitting the data for a different purpose.
  • we are required to store when consent was given, what exactly was signed up to, and what purposes/channels the consent applies to. While we have the date in the group history, we still need the purpose (could be inferred from the name of the group, but then this must never be changed later on), and the statement. For consent that is given over the phone or face to face, we are also required to record these details, methods, and which staff/volunteer was involved in taking the consent. I'm not sure you could store all this metadata on a CiviCRM Group. I think it would have to be an activity.
  • it must be as easy to revoke consent as it is to give consent. I think the group model could work for this as I suspect there's less requirements around recording how it was revoked.
  • we need to be able to search on consent. The group model is ideal for this; if they're in the group, they've consented. Sorted!
  • it expires. Although organisations have some liberty to define when. I'm not sure how the 'last did activity type X' summary can be useful for this? If consent is given and re-given with certain activities it must be recorded each time. The group model is not so good for this because it basically means "joining" a group you're already a member of; I think you'd need to (a) update the joined date on the group and (b) add another record to the group history log.

The "contacts who have not had activity for..." table is useful but I think that we need to get a list of contacts who have not done any of the selected activities over that period. e.g. if I've done activity A ages ago, but did activity B yesterday, I would still show up in the clickable list of people who have not done A for ages. Perhaps I've misunderstood how that is supposed to be used.

I'm interested in the right to be forgotten functionality since I've recently written the same functionality for another client who will regularly need to anonymise contact information while keeping activities etc. For them I wrote it as a search task, so they could do a search, pick the people they want to zap and anonymise them en masse. Obviously here the organisations have to be super careful in who they pick!

Thanks,

Rich

We've released a new version which should deal with most of issues you've raised, specifically bringing all the communications preferences together including group subscription and acceptance of data policies. We've produced it as a stand alone page to ensure its not caught up as any form of incentive and it also means that the organisation can keep all of its wording in one place. Please do take a look and let us know how you get on.

What about the Drupal side of things? What if a user logs in and cancels their account via user/edit - does that automatically delete or flag their user record/data in CIviCRM?