• 
• 
• 

Tweet

• Data Strategy
• GDPR
• Privacy

04 Dec, 2019

Data Protection And The Use Of A CRM

Lawful Basis

It may not be obvious that a CRM may store data which is being processed for different purposes. Therefore, it should be possible (and required) to tag personal data for an individual according to one of the six lawful bases permitted by GDPR Article 6. Some data will rely on consent for processing, while other data may rely on legitimate interests, public task or contract fulfilment. The CRM should track the lawful basis, and if it is changed, maintain an audit trail showing when the change occurred – for example, if a prospect becomes a customer, the purpose may change from marketing with consent to contract.

In the case of special category data, the Article 9 exemption permitting such processing must also be linked to the data items.

Privacy Notices

Depending on the source of the data stored in the CRM, a Privacy Notice is sent without delay (Article 13—for data received directly from the data subject) or within a calendar month (Article 14—for data received via a third party.) Typically, this depends on receiving a valid email address for the data subject, so that an email with a Privacy Notice (ideally a PDF) may be attached. Where a PDF version is not available, it may be permissible to send a URL to the current privacy notice on a website. Consideration should be given to use of post or Fax to notify, where an email address is not available. Voice recordings of verbal consent may also be collected and stored for future reference.

The Privacy Notice should explain the following:

1. The type (categories) of personal data being collected and stored within the CRM;
2. The source of the personal data – who provided it, or how was it obtained;
3. The purposes for which the personal data is being collected and processed. Where multiple purposes are envisaged, each should have its own separate lawful basis;
4. The lawful basis for processing. Typically, only one lawful basis may be selected for a single purpose;
5. Where special categories of data are being processed, the relevant exemption under Article 9 should be cited;
6. With whom the data may be shared, and the reason for doing so;
7. Where the data is being stored or processed in a 3rd country (outside E.U./EEA), that country must be identified, along with the transfer mechanism being relied upon (e.g. Standard Contractual Clauses);
8. The retention period, i.e. how long the data will be retained before it is deleted or anonymized;
9. The rights available to data subjects in relation to the data being processed, and how the data subject may exercise their rights;
10. The possibility of automated decision-making in respect to the data (this should be present even if not being used, to make it clear that there is no automated decision-making taking place);
11. The date that the privacy notice was updated, and a summary of changes since the previous version;
12. Contact details for making a complaint;
13. Who is the Data Controller, plus any Joint Controllers or Processors involved in processing (or other categories of recipients);
14. Technical and Organisational Security Measures for protecting the personal data;

Note that a Privacy Notice is not a contract, and therefore does not require agreement or consent. Rather, it’s a statement that is intended to satisfy the Fairness principle, to fully inform data subjects about how their data is being processed.

A Privacy Notice (also known as a Fair Processing Notice, and inaccurately as a Privacy Policy) should be updated as changes are made to processing. Ideally, the changes made should be highlighted, along with the date of changes, in the privacy notice itself. Significant changes to processing may be notified to data subjects at the discretion of the Data Controller by issuing a fresh Privacy Notice. This can be used as a reasonable means to update Privacy Notices where these may have been neglected in the past.

Do Not Call Registry (TPS)

If there are plans to call one or more of the persons listed in the CRM for marketing purposes, the provisions of the Privacy of Electronic Communications Regulation (PECR 2003) come into effect.

Specifically, this means that for the U.K., the numbers in the CRM should be screened on a regular basis against the Telephone Preferences Service (TPS), and where there is no explicit consent granted for telephone marketing, the number found in the TPS may not be called.

Ideally, the TPS registry should be refreshed each month, in case there are changes.

Note that the remit of TPS is strictly calls of a marketing or political nature. Market research or SMS messages are not covered. Your institution may not send marketing texts without explicit consent for this purpose, which should be recorded by the CRM (including who granted consent, what it was for, and when.)

From the perspective of the Data Controller, there are two checks that must be made (and therefore supported by the CRM system) prior to making any marketing calls. First, the number to be called should be checked against the TPS1, and where there is a match, then only if specific consent has been granted by the data subject, a call may be made. With a TPS match and no overriding consent, no marketing calls are permitted. Secondly, a check should be made to see if the data subject has opted-out from all communications (i.e. right to object to processing.) If they have opted-out, no communication may occur.

Note that postal marketing communications should be handled in a similar manner, although they are more permissive in regards to not requiring prior consent. They do however require respect for opt-out, and the checking of restrictions with the Mail Preference Service (MPS2.) In rare cases, if Fax is planned to be used for marketing communications, this should be checked against the Fax Preference Service (FPS3), which is operated by the DMA4.

Subject Access Requests

When a data subject submits a SAR, the CRM is one place which should always be checked for the presence of personal data of the specified individual. The employee responding to the SAR needs a search interface that allows the various rights to be implemented.

Right to Be Forgotten

The CRM should maintain some sort of audit trail that tracks when a data subject exercises their right to erasure, also known as the right to be forgotten. A record should be kept showing whose data has been deleted and when. Ideally, a one-way hash (such as SHA-256) should be used on the email address so that it can be checked in the future, but still protects the privacy of individual whose data has been deleted. Obviously, this data should be purged from backups or archives too.

Data Retention

A mechanism for deleting expired personal data should be implemented and tested, and must have a suitable audit trail. It’s a requirement to specify a definitive period for retention. This should match the information provided in the Records of Processing Activities (ROPA), as well as the Privacy Notice.

Remediation

To satisfy the principle of Accuracy, there should be a mechanism to assess the quality of data entered into the CRM. For example, an email bounce should trigger an assessment of poor quality. Where data may be low quality, governance measures should be used to correct erroneous data—which is also one of the rights of the data subject. Another right that the CRM should support is the right to export data in a machine readable (portable) format for individual records. Portable data formats may include CSV, XML5 and JSON.

Batch Updates

Caution should be exercised when new employees are hired who may bring with them a substantial collection of contact details from their previous employer. There is no lawful basis for loading in such data without prior consent, and indeed this may expose the institution to a risk of prosecution if the data was shared without authorization (a breach of the Computer Misuse Act), as well as breaching the Data Protection Act.

Similar caution and extreme skepticism should be employed when buying-in mailing lists for marketing purposes. On the other hand, there may be flexibility if a few contacts are added prior to sending out a communication, where the data subject is known personally to the new employee.

Migrating to a new CRM should be seen as an opportunity to purge stale or low-quality data.

Data Minimization

When loading data into the CRM, a decision should be taken as to the relevance of whether all available data elements are necessary to achieve the purpose of processing. For example, it is doubtful that date of birth would be strictly necessary, therefore this should not be loaded into the CRM.

Privacy By Design

Care should be taken to ensure that the CRM uses features which support privacy. For example, individual accounts with authentication requirements must be used to add or process personal data, and logs should be kept of actions (such as exports) that affect large volumes of data. Various levels of access to different categories of data should be mandatory, and data field masking should be used wherever possible.

Highly sensitive data (such as government-issued ID, credit card numbers or PAN data) should never be stored in the CRM itself, but rather replaced by tokens where required. The personal data should be encrypted when not in use, e.g. through an encrypted file system and encrypted backups. All data transfer links must use encryption.

Note there may also be implications regarding your choice of CRM vendor, such as non-EU-based (data residency issues) or support by 3rd-country personnel (India or Philippines.)

Understanding Risks

When there is potentially a high risk to the rights and freedoms of data subjects, then a Data Protection Impact Assessment (DPIA) may be required. Ensure that the data lifecycle of the CRM is clearly understood, and that relevant risks and appropriate mitigating controls are in place, documented and tested with independent assurance. Every CRM should be assessed for the necessity for a DPIA.

Consent

A single collection of an individual’s consent may not be sufficient, especially where a CRM is integrated with multi-channel marketing. Specific consent for individual purposes may be required, such as that which overrides a TPS preference block. Whichever forms of consent are used, the following key principles should be observed:

1. Consent must be as easy to revoke as it was to grant;
2. When responding to a SAR, consents must be clearly delineated for the individual;
3. An audit trail is required, showing when consent was granted, and for what, and by whom.

Segmentation of channels and their associated consents are always preferred when doing electronic marketing, e.g. being able to distinguish between a monthly newsletter and bargain alerts which may be time-sensitive push notifications or special offers.

More sophisticated CRMs may actually be able to generate consent collection and preference management forms directly on your web site. Ensure that this doesn’t increase your attack surface area by exposing additional interfaces to public access, and require two-factor authentication for administrators.

Audit

Based on the accountability principle, it must be possible for the CRM to be audited in order to demonstrate compliance with GDPR and related laws. This should include appropriate language in CRM supplier and support contracts (i.e. a data protection addendum), as well as data sharing agreements with joint controllers if applicable.

Data Breaches

CRM data may be subject to a data breach. Appropriate policies should be in place to record and respond to them, if they occur. Due to the nature of the data, breach notification will likely not be required, although if quantities of data are large, this calculus may change.

Training

In addition to regular cyber security and data protection training, new employees should receive induction training which emphasizes what they can and cannot do with the data in the CRM. A special focus should be placed on restricting the risk of new employees bringing contact data with them from their previous employer, and reminding departing employees during their exit interview that they have similar obligations. Naturally, this should be made part of acceptable use policy.

Summary

A CRM system is integral to the appropriate managing of the relationship with customers, and represents a significant asset to the business. Clear lines of accountability should exist, not just for the technology platform of the CRM, but also the custodianship of the personal data contained therein.