When constructing a consent/permission management model, be that for marketing permission management or to meet the requirements of emerging citizen data privacy regulations such as GDPR, PSD2 or ePrivacy there are a number of elements and concepts that you should consider particularly if you are planning to build your own technical solution.
The Building Blocks of a Permissions and Consents Framework
When building a consent/permission framework often the focus is first on the statements that your client or prospect is presented with when you are capturing their data such as the below.
However this approach often has a scaling problem when searching your data system for the valid permission to use in a campaign, communication or data processing activity. Breaking down a permission/consent into its constitute parts has often been found to deliver the desired scalability. An approach we like suggested by the UK ICO and used by Consentric in their application design is to break a permission into a 5W framework:
The 5W’s suggests six(6) parameters to be managed in the Permission/Consent framework of which four(4) are documented when you design a personal data process eg sign up page for a weekly email newsletter.
Under GDPR permissions/consents need to be categorised by a legal justification. The legal justification can affect the way you capture the permission/consent and the way that the Data Subject ( the persons whose data you are processing) grants and denies that permission/consent.
Below is an example of options that might appear in the design time parameters of the framework for supermarket. These parameters values appear in the various Davies March Permission and Consent Applications and demos for our example Supermarket Daviesmarché.
Creating Permission and Consent Statements using the framework
Constructing a permission or consent statement to present to Data Subjects when capturing personal data or when communicating on data processing is done by assembling a value from each of the design time parameters. The table below gives examples of these as well as wording of the related statements that you would present to the Data Subject. The permission key is a unique identifier for the permission record that is also used in the recording of permissions and consents which is described further down.
Collecting a permission or Consent that applies to all Business Functions
In a number of implementations we have found that clients would like to collect the same permission/consent across multiple Business Functions such as a general marketing consent.
It could often ba a negative user experience during signup/data capture to ask the Data Subjects consent for the same purpose and data/Channel across multiple Business Functions as below.
To allow the question to be asked once but applied to all permission/consent records a 'Permission Group Key' is added to the framework as per the example below. The Permission Group Key is then added to digital and paper forms the same as a Permission Key would. You also have the opportunity to allow data subjects to Opt Out at the Permission Group Key level or at the more granular Permission Key.
The Framework in practice
Bringing all this into practice below is an example of the framework deployed for a charity and the interface for switching on and off permissions and consents for people in your customer database.
Governing Permission and Consent Creation
In order to ensure that Permissions and Consents are created in a consistent fashion, that there are no duplicates and that stakeholders have signed them off you should look at the following assets and procedures:
- Central master of Permissions and Consents
- Process in which staff creating new data capture interfaces and data processes can propose a permission or consent statement with documentation of the approvals and signoffs
- Documentation of approver review that permission or consent is ‘good’
- A method for expiring or ending consents
To help you with this we have a Excel workbook you can download as well as an Outsystems Forge component.