Consent Management

Although GDPR has standardised privacy policies across Europe, per language, region and division you may need to implement different policies. And policies change over time. At best enforcing policies can be called inefficient and not scalable.

When (new) policies are published, iWelcome collects the user consents on these policies. These 'document' or 'policy' consents are centrally stored and made available for the end-user as well as for the DPO.

Policy enforcement is configured in the registration and login flows. The iWelcome UI can be used, or the customer can build own UI and integrate via API's.

Consent under GDPR needs to be given by end-users (data-subject) for the processing of personal data (unless one of the exemptions of article 6 applies).  That consent needs to be “freely given, specific, informed and unambiguously”. In other words: it must be crystal clear. Organisations need to be clear on what they are using an individual’s personal data for, the individual needs to be well informed about it and must make his or her decisions freely. Pre-ticked boxes that need to be un-ticked are also specifically forbidden in GDPR as this may indicate a preferred choice.

This rule impacts CIAM systems as storing the data is – by law – called “processing”. And as most personal data will be stored in the users profile, a key section in a CIAM system, consent mechanisms need to be present.

iWelcome provides a unique database structure for consent, leveraging the NIST 8112 standard for meta-data. For every data-attribute of a user, multiple processing purposes can be stored. Examples are that an email address can be used for new product information, and customer care, but not for marketing. 

Course grained consent is not specific and is therefore not allowed under GDPR.

Consent according to GDPR needs to be “freely given, specific, informed and unambiguously”. In other words: Organisations need to be crystal clear on what they are using an individual’s personal data for. As a consequence, there can be multiple processing purposes per data-attribute. Let's take the example of an email address. This can be used for self -service, for customer care, for new product information, for marketing, etcetera... and the customer decides!

With iWelcome you can store multiple processing purposes per data-attribute, just like GDPR requires. That is the advantage of the flexible (NIST 8112) meta-data model that iWelcome uses. The processing purposes can be propagated to other applications so that these applications are aware of the specific choices of the 'data-subject'.

The requirements of modern privacy laws drive the need for a new data model. For every data-attribute multiple processing purposes must be stored, as well as retention policies. Also anti-money laundering rules in the financial services industry, referred to as 'Know Your Customer' do require information about the data-attribute, like the origin of the data-attribute and the Level of Assurance (LoA).

Combining these needs, iWelcome has foundational implemented a new data model, based on the NIST standard for meta-data, NIST 8112. Meta-data is at the core of this data-model. For every data-attribute additional information can be stored in the meta-data, like:

• Last update
• Mandatory y/n
• Provider name, e.g. "Facebook"
• Multiple Consents
  • Processing purpose, e.g. "customer care"
  • Y/N
  • Date
• Verifier, e.g. "not verified"
• Classification, e.g. "confidential'
• Data deletion, e.g. "12 months after last login"
• Expiration date, e.g. "12 months after last update"
• Parental control y/n
• Parent ID's, e.g. User-ID's

This data model gives iWelcome sheer unlimited capabilities for implementing fine-grained consent, Know your Customer, Parental Control and data retention policies.

There is no such thing as a standard for customer identities. Depending on the case it is build up from portals, apps, internal and external validations, back-office and third party applications. And at the same time GDPR requires you to keep an up-to-date inventory of consented data. this drives the need for a Single-Source-of-Truth that can, not only integrate identity data, but also integrates consent data.

This is exactly where iWelcome's Consent-API comes into play. The Consent-API is a core element for collecting consents from other systems.  A customer dialogue in a portal for Just-in-Time consent "may we know your <data-attribute>, so that we can <processing purpose>", can easily integrate with iWelcome via the Consent-API. This foundational component is used by any interface with the customer, even the native interface iWelcome provides.

Consents also need to be interfaced with other applications. iWelcome provides an 'event API' and customers can use the Consent-API' for collecting consents stored in iWelcome's SSoT for consented identity data.

Detailed information can be found in iWelcome's Developers Portal.