I don’t know you people


This post will focus on what needs to be considered when designing a solution for managing GDPR compliant communications and consent in a CRM system. No specific CRM system is in mind here, each environment will have it’s own requirements but the main design points will be common across most CRMs.

I’m not going to go into detail on GDPR but see here and here for some background info. Suffice to say that most CRM systems in place at NFPs will need some updating to store the additional information and manage the new complexities inherent in the stricter data protection regulation.

There are three general areas of a CRM that will need updating to manage GDPR compliant consent and rules; Contacts, Cases and Consent/Comms Preferences.


There shouldn’t be major changes needed to Contacts, just adding security to specific information for compliance (some of this is already required by the existing DPA which I’m sure everyone is fully compliant with….)

  • Any sensitive data must be protected and only visible to users who need to see it. In general, organisations require stronger grounds to process sensitive personal data than they require to process “regular” personal data. This could be achieved with field level security or similar on the relevant fields. Sensitive personal data are personal data, revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership; data concerning health or sex life and sexual orientation; genetic data or biometric data.
  • Clearly identify Contacts that are under 16 years of age as they require additional consent from their parents. 16 is the current parental consent age in the GDPR. However it’s highly likely that the parental consent age for digital communications will be lowered to 13 in the UK to match current regulations. Either way the Contact record must clearly flag children and ensure that parental consent information is presented when needed.
  • The Contact record should show the first consent information that generated the record. This isn’t required specifically by any regulation but it would be helpful to quickly see what the first point of communication was or the source of the Contact, particularly if the Contact came in from an external source.


The GDPR creates some new rights for individuals and strengthens some of the rights that currently exist under the DPA. Therefore the CRM Case system should be updated to cater for the new kinds of requests that supporters can make. My suggested new Case types are:

  • Rectification
  • Erasure
  • Restrict processing
  • Access/data request
  • Objection

The Case record will need to store the details of the request and the actions taken, which should be standard functionality.

Contact Consent/Comms Preferences

Finally the main part of the design. There will need to be a table/entity/record that stores consent information received from or about a Contact. There may be an existing data structure in place, e.g. Communication Preferences, so there will need to be a decision whether to update the existing structure or create a new one. The standard “Allow/Do Not Allow” flags on communication channels in most CRMs will not be sufficient or compliant.

The key parts to recording consent will be:

  • Source of the consent (e.g. staff, external agency, etc.)
  • Time & date the consent was received
  • What the consent was given for or not for
  • How was the consent captured (phone, email, in person, etc.)
  • What language was used in the consent statement/fair processing/data protection statement

The last point is important. You will need to be able to tell what language was used when the consent was captured. For email or post communications you could link the consent record to a template or the specific example of the communication. For phone or in person collection you’ll need a way to store the statements that would have been used at the time the consent was captured.

Consent under GDPR can now cover data processing, so you will need to get consent from supporters for wealth screening and similar processes in addition to the “regular” consent needed for communications.

There is no specification in the regulations to say whether you’ll need to manage consent as “opt-in” or “opt-out”. Either way can work so the system design will be driven by the business decision on that front.

There will need to be a relationship between a consent record and a secondary Contact in order to manage parental consent. As mentioned above additional parental consent will have to be stored for children.

Consent refresh

It is highly likely the most difficult part about designing a solution to manage GDPR consent will be bringing your existing data up to compliance. There is a lot of supporter information in CRM systems across the sector that doesn’t have the required level of detail. You’ll have to decide on how you want to refresh or discard those records so care will be needed when creating the design to make the upgrade/migration as easy as possible.

For advice or further information about designing a consent management system in CRM or on managing a supporter consent refresh please get in touch via the contact form or email me.

And finally,

In related fun check out the webcast of the ICO Fundraising and Regulatory Compliance Conference on Tuesday Feb 21st. The event venue reached capacity very quickly due to “high demand”, which is unsurprising. Hopefully the webcast will cover a lot of the conference, I’d expect it to be well attended.

Also, Saturday the 28th Jan is Data Protection Day, I’m not sure how to best celebrate Data Protection Day, maybe an unbreakable piñata with contact info inside? Any ideas on how to best celebrate this important holiday please let me know.

The FPS is also coming. I’ll have a post for dealing with that, once we get any useful technical information on the service.

As always comments, questions and requests are always welcome

Leave a Reply



Phone: (+44) 074 1215 7299
Email: info@nfptech.co.uk