Consent Lifecycle Management integrated with your or our IAM system
Consent for the processing of personal data is a major theme in GDPR. It should be given “freely, specific, informed and unambiguously”. iWelcome provides the foundation for the customer dialogue, 'flows' for progressively capturing data and consents in an advanced meta-data model:
Allowing consumers to view, edit, download and delete their personal and consent data is not only a strict GDPR requirement: it is one of the cornerstones for building trusted consumer relationships.
With iWelcome's consent solution, you can either use a
In a heterogeneous IT-environment with front-office and back-office applications, Data Privacy Officers have a hard time fulfilling their legal obligations for keeping an up-to-date inventory of data collected and their processing purposes (GDPR article 30).
iWelcome traditionally provides the Single-Source-of-Truth (SSoT) for Identity data. With CLM, iWelcome also provides the SSoT for consented processing purposes. Consents are stored in iWelcome's (meta-)data model and kept actual. Changes in consent data are automatically propagated via the Consent-API for use by all other systems. As a consequence DPO's have their up-to-date inventory and reports at their finger tips.
Many organisations already use customer registration and login, either home grown or a SaaS product. With GDPR they are confronted with new legal requirements that can not be fulfilled. At the same time they do not want to disinvest in their current solution.
iWelcome Consent Lifecycle Management is the perfect solution. It can be delivered as separate module, complementing an existing Consumer IAM ecosystem. All fully API-based, minimising the impact of integration. With this CLM-as-a-Service, you can offer full control to consumers, while allowing your own staff to optimise internal processes as customer care, auditing and cross- and upselling.
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:
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.
Some companies have an existing CIAM solution, but integrating Consent Management is complicated within that existing infrastructure. iWelcome has set up a CLM proposition that can be delivered as a separate module, complementing your current Consumer IAM solution. Our CLM proposition is fully API-based, so the impact of integration will be minimal and on organisation can become GDPR-proof at reasonable cost.
The data subject can access the personal data that was collected and make corrections and updates
With consumer data being stored and managed in different back-end systems, DPOs face a difficult and labour-intensive task. In many cases, proving GDPR compliancy requires extracting data manually from a number of different back-end systems.
With the iWelcome CIAM solution, all data is stored and managed in one platform, including all consent data. Not only the actual consent, but also the processing purpose, date of consent, data retention policy for consent: it is all there in one overview.
iWelcome's way of storing consent enables organisations to create one 360º-view of their consumers. This helps marketing & sales for cross- and up-selling, customer care can provide better support and compliance officers can gather all required consumer identity data from one single source.
"She said yes!" is the ultimate consent when people are in love. In business users will not be that enthousiast, but proper questions at the right moment are the basis for trusted digital engagements. Embedding consent in your dialogue design is referred to as Just-in-Time (JIT) Consent.
When should consent be requested?
First of all, consent should be requested when individuals are asked for input of (new) personal data unless one of the exemptions applies (for instance the processing of data “for the performance of a contract”, GDPR article 6).
Asking for a delivery address for a book that the individual ordered in an online bookstore is fine, but you can only use the information for that purpose and nothing else unless you ask for consent (specifying information and reason) for that. Asking for a phone number in case there is a problem sending the book is fine if you specifically mention that use and leave the choice up to the customer. However, you are not allowed to use the phone number for anything else in the future, so it is better to keep it only for a month (retention) and/or ask consent to store that information for further order tracking as well. For sensitive personal data like biometric data or genetic data, you always have to ask consent (unless one of the exemptions of article 9 applies). In the law this is referred to as “explicit consent” meaning that you have to do an affirmative act which can be to check a box to confirm that the data you have just entered will be used for the reason specified. In the case of the delivery address, it was enough to mention at the address box that the address would only be used to send the book. Without the need of a tick in the box.
Consents stored in iWelcome can be integrated in SAML- or OIDC-tokens. Relying parties can use this information for opening or restricting their services. Privacy control is at the heart of your information flow.
