Good afternoon, ladies and Tren. Welcome to our cooking cold webinar consent lifecycle management, consumer identity management's core capability. The speakers today are corn and Roy who is vice president product and strategic Alliance with IWE and me Martin Koran, founder, and principle Analyst at cooking a call. This webinar is supported by IWE. Before we start with our webinar content, some quick information about keeping a call and about the flow of the webinar.
So cooking a call, we an Analyst company, we an international company with people in Germany and other European countries in Australia and the us, we provide information on various topics. Our main focus is information security with a strong emphasis on identity and access management, where we sort of have our roots. We provide research. So for instance, our leadership compass documents, which compare vendors in different market segments. We look at product, we look at strengths and other things we do advisory for both end users and vendors.
So product selection, strategy, maturity assessments, and all that stuff. And we do events like our currently running consumer identity event in the us like our European identity and cloud conference, which is our flagship event, which will be held next time in may next year. And we will, we also do a lot of other events, including our webinars.
We have a couple of upcoming conferences. So one is running, as I've said currently, then we will do the consumer identity world conference also in Paris in November.
And then in Singapore in December, we will do a marketing executive summit in February and our next additional digital finance world as well in February. So we have a couple of upcoming conferences, have a look at our website, some guidelines for the webinar. You are muted centrally, so you don't have to mute our with yourself. We are controlling these features. We are recording the webinar and the post recording will be available tomorrow. Also the slide deck we are present and will be made available for you for downloads. So those are recording on the slide.
X are accessible soon after the webinar, there will be a Q and a session at the end. So feel free to enter questions at any time so that we have a long list of questions we can pick from when we do our Q and a session at the end with that, I let's have a look at the agenda.
The agenda for most of our webinars consists of three parts. In the first part, I will talk about the business aspects of consent management and the second part in Carney, we'll talk about conceptual building blocks for consent management and the consent lifecycle.
And then the third part we will do as I've already said, our Q a session. So let's directly start. What do we talk about? Consent has to do a lot with GDPR. So when we look at it in more in detail, and it's not, it's far less informed 35 days to go.
I think, I don't think I recalculated the number, but it's not that long anymore. So before the G GDPR, and I think it's important to just have the background about GDPR for understanding why we talk about consent here. Each EU member state has its own data protection laws, and there was an EU directive which needs to be transposed to the national legal system with the GDPR we, which becomes effective next year.
May we have a regulation? The difference between a regulation, a direct is basically the regulation overruled the national law.
So it's, it's really a sort of an EU law, so to speak. And so there's not that much time left. So there were two years from when it became sort of entry into force and the applicability and this timeframe is so, has mostly passed right now. So we have a harmonization at the U level. It strengthens existing data protection standards, and it also binds businesses established outside the EU to the European standards when operating in the UE or the economic region here, the point, which is important to understand is in fact, it's binding once you do business with EU residents.
So just as sort of the simplest way to describe the impact. So it's something which is relevant for all EU countries without transposing it into international legal international law.
And it, in fact, also non EU companies, and one of the most important things, I will touch this on the key aspects right now, one of the most important things is consent within GDPR. One of the biggest changes we have to observe and change, which is highly relevant because it affects the way we, we work.
And we, we communicate, we interact with our customers. This is consent and consent. And in fact, the GDPR says unless another legal basis is in place, which might be a contract consent is required prior to processing personal data.
This consent has to be freely given informed and ambiguous, and it needs to consist of clear statements of affirmative actions. So when we look at today's world of cookies, which say this website uses cookies, agree or leaf, so to speak, this will not be sufficient anymore. There needs to be more information about what is done with the data.
And it's really, you know, freely informed, clear statements. This is far more challenging than just saying we use cookies and agree to them. Consent should be given per purpose and might be revoked at any point of time. There are two highly complex complex elements, and the one is constant per purpose. So if you collect data of your customers or consumers and you process them and storing is processing and you use it for different types of purposes, or you add a purpose, then consent must be given per purpose, not once, but per purpose.
And the customer might decide to revoke consent for one purpose while he, the consent remains for another purpose, that's not easy to handle from a data model perspective, from a data handling perspective, because it also can be revoked. Then we have some other aspects which go beyond concern.
One is you need a data protection officer, which can be external, which is not a big challenge for some of the countries where this, the data protection officer is already required while it's challenging for other countries under certain circumstances, for instance, for specific types of data or the monitoring of public places, etcetera specific data protection impact assessments are mandated. One of the also very challenging things is data breach notification within 72 hours.
That's not a long period of time.
You need to be prepared to notify about a data breach, which affects PII, because if you only have 70, 72 hours, three days, then you need to act very rapidly. And we will see far more notifications, I believe starting next to me, because then everyone has to notify. There are massive data control rights of the users, which also are very challenging from a technical perspective.
So the right to be forgotten, you need to understand where the PII resides to enforce this, right, the right to freeze the processing of the data, the right to export it, edit it to bring it back all, not easy to sing, to solve privacy by default and design are mandatory. So a lot of things which are changing within the U within or by the U U GDPR and consent is one of the most important ones.
So how big is the real impact of the GDPR? I think it's definitely an impact. It depends on the country. You are on the way you currently deal with PII.
So do strong privacy regulations already a play life. You say, yes, the impact will be lower them. If you're operating from a country or in a country where you don't have that strict regulations, do you only use the data for one purpose or for multiple ever changing purposes? The more so one purpose is easier to handle the multiple purposes because it's consent for purpose. Do you have your DPO or not? There might be some country specific exemptions defined, but they will not give much room.
So some countries might try to loosen the GDPR a little, but if it's too much, it will automatically end up by the European court of justice. And I assumed that they will be very strict.
So it's hard to predict that this will happen. Are you technically able to support requirements such as right to be forgotten the constant for purpose and all that stuff? This is probably the biggest challenge. Where does C PI I reside? How can you stop processing? How can you delete it if you are allowed to delete?
And you might end up with a situation where you must delete most of the data, but you're not allowed to delete all of the data because some other, some data might be, must be kept potentially due to other legal requirements. Do you have security by design and privacy by design as principles already implemented?
If yes, it's easier than in the other way. So GDPR is a challenge, but there are also business opportunities by GDPR. So amongst these op opportunities, I see one as the same, but you have the same regulations for everyone doing business with your residents.
So that same chances for everyone, the second one. And then we come to and we dive more into the content part, even within the next couple of slides, consent means clarity. So it's lot of moving away from this gray area for uncertainty where you don't know exactly. Can I do that with the customer data or not?
And I've seen so many discussions about what can I do not to, yes, I have clear content. And if I have content, I can use the data for that purpose. It makes things clear. You can increase customer loyalty. So if they give you content, and if you deal in a way with the data, which is seen as positive by your customers, you also might improve customer loyalty.
If they understand, yes, there's a value for them by giving you PII and giving you consent, then this might some be something which sort of helps you in also differentiating from others by saying, okay, you know, we trust, use the data we need.
There's a good reason for doing so. And you might differentiate in a positive way by being the, sort of the trusted partner of your customer. Another interesting part is that one of the elements also in the GDPR data portability, so the customer can take is data and Porwal someone else.
And if you're clever, you support the sort of the transfer of data from others to you. So become the target, not the source of data portability. So what is the business impact of consent management?
Again, it's, it's about, you know, the relationship between business and consumers and the consumers clearly get some more power here.
If I look at a consent requirements, more detail, I already touched some of these given by a statement of a clear affirmative action. So it's not that by not doing something you agree it's so the opt out scheme does not work. It's about clearly saying, I agree. I give content and that's it. So silence breed, tick boxes or inactivity is presumed inadequate to confer consent.
We, this really given specific, informed and ambiguous already another requirement is it shall be as easy to withdraw consent as to give it today. It's really as easy. And this is something which might require major changes to your websites and to your applications for certain special categories of personal data. There needs to be given, cause that needs to be given explicit for that type of data. So it's PII, which can rele racial or ethnic political opinions. Cetera.
Again, the point is that is not only if you look at political opinions, something where you say, okay, I'm member of that power politically party, it's something which can re Wiel that information.
So this also can be something which is sort of allows indirectly to conclude some other information. So then we have the parental consent for processing children's personal data, which ends up with the requirement for family management and other stuff.
If you are processing children's personal data, which again adds another level of complexity and there needs to be explicit consent to make decisions about a data subtract based solely on automated pro processing, including profiling. So if there are decisions made based trust on the data, this, or there is also need for explicit content and which makes it even more complex, the customer sort of data subtract can also ask for an explanation of how does what's the decision made, which makes it hard to use non-deterministic algorithms.
So all this fussy machine learning, AI, blah, blah stuff, might come to a limit when it's about automated profiling in the context of GDPR.
So when we look at it from a business perspective, right now, there's an obvious impact on the user journey and the constant life cycle. So when we have the cookie up today, there little impact, the cookie pops up, everyone is used it, and then he leaves the website where he says, okay.
So I think usually these are the two options with explicit, with management, with content per purpose, but with the need for requesting additional purpose consent for additional purposes and so on, you need to re rethink the user journey and the entire content lifecycle. And it means you need to re rethink the way you interact with your customers and your consumers.
So it's not just that you say, okay, instead of the cookie thing, I provide more information, say here, the tick boxes tick them. And then this will not really work.
You need to think about how can I, you need to do it at some point yes. Before processing PII, but you need to think about how can I do it in a way that a customer accepts that he understands it, that he gives the, so don't leave the customer back with questions about why to give consent. Think about all this process right now, from a customer perspective or a consumer perspective, what does it mean for him? And so at the end, it's a very simple thing.
People will give consent if they feel that there's a value, they got an exchange, but they will question giving consent for things where they don't see a big value.
So that might be the point where you say, okay, yes, for using the search capabilities, there's a clear value. And I even might, might get some personalized search results, but I don't want the personalized Edwards because they don't work well anyway. So that might be a, be a consequence that some of the parts which are relevant from a business model are harder to, to, to obtain content for than other parts are.
So I think it's very important that you demonstrate a value of giving content by explaining the benefits for the customer, if they are such benefits. That really challenging thing clearly is if there's no to little benefit to the customer, but a lot of benefit to you as an organization, by whatever reselling PII, cetera, reusing PII, then obviously it'll be hard to explain will be interesting to us to see how customers react and how, which part of the customers then will say, okay, I book that for that purpose.
Well, as I said, it will be definitely interesting to, to see what happens here.
You need to identify, that's a part corn will touch on very deeply, identify easy and low intrusive ways for requesting additional consent prepared by informing about it beforehand as well. So you might then say to your customers, okay, we will add this. We'll inform you upfront and blah, blah, blah. And before not just say at that point, you bring up before you further use of website, give content to that new purpose. That's not enough.
So might need to redesign parts of your websites early and standardized content management and overall consumer identity management at corporate level. And that's something, you know, with only eight months left eight and a half months left, it's latest time to start, and you probably will need some technology, which sort of standardizes the content handling. So don't try to reinvent the wheel, but rely on things which are already available.
So how can you convince the customer about the value of consent? So why demonstrate or explain the benefits?
You also might add a benefit each by lottery is our stuff. So I trust while ago received an email, which said, oh, we have this, this great lottery with some, some interesting things to win.
And I, I really thought about, and, and, you know, if you give us the, the consent for sending you emails and some other stuff, so if give us some sort of consent, you can participate in the lottery and there drawings and these, and these things can be, you can win these and these things. And there were some interesting things I really considered giving my content because there was a benefit.
And I, I was particularly interested in winning the ticket for the buck open air, which is a heavy metal open air in Germany.
I finally decided not to give the, but you know, it even brought me as someone who's very privacy, a fan. It brought me to sing another point, which might be interesting. And that's something you should really should think about very roughly. So if you're someone who currently earns money, primarily with, for instance, Edwards and other types of businesses, the under each U GDPR might offer the door to free models.
So you might end up with something where you say there's a restricted sort of a limited functionality. There's a free version paid by PII. There's a paid version where you say you restrict the PI used, so no Edwards and other stuff, and you pay with money. And there might be far more people willing to go to certain paid services, just because of the fact that they better understand what is done with their data. So then the need for per purpose and informed consent also will lead to a, to a situation where people are better informed about what happens with the data.
And that might increase the willingness to pay with money instead of pay with PII.
And clearly it's also about thinking about why not giving some control back to the customer. So there are various concepts that I don't want to dive into detail, but we have a lot of publications around life management platforms. There is the vendor relationship management concept. That's the concept of self identity, which is currently intensively discussed there, various models here. And it might be also that you say, okay, maybe I don't need to collect that much PII.
I just requested when I really need it in a different way. So if you don't wanna monetize PII, maybe you don't need to collect it. Also think about that because it will make it easier to obtain concern with that by hand, over to Carney, who will do the second part of the presentation and Hebrew right now, talk about conceptual building blocks for management and the consent life cycle coordinates your term.
So this part of the webinar will cover the essential building blocks of management. And as you will see, when I go through it, consent is a constant changing thing.
And as such a better name for it is consent life cycle management, which you will now see more popping up as a, as a generic term. And as far as I know Martin, you were the one, the first one to mention that, that topic, the ICO, which is the independent authority in the UK about data protection wrote a very good consulting paper on consent within the GDPR. So this is for most people, I think master read what to do and whatnot, but also the concepts are in that, in that paper, it's still a draft on the internet, but final versions will be per soon in that consultation.
They talk about the need for clear more granular opt methods, such as records of consent and simple, easy, easy of access, easy to access to withdraw that consent. They describe a more dynamic idea of consent consent as a organic, ongoing, and actively managed choice and not a tick box like the KU law that was just mentioned. And they have an advice on how to manage consent.
Like Martin mentioned, it's all about that ongoing relationship of trust with the individual, the consumer, and they advice to look at privacy dashboards to offer so people can easily access and update their consent and also get control over that kind of information.
If you look at consent and specifically the different services you, you will have to offer, it's basically comes down to the following five building blocks to be offered by user interface, as well as open APIs.
First, there is the moment of the consent request by the organization, the data controller that will evoke an action and question or request that depends to the specific individual. Then there is the possibility, the needs to be more exact to constantly change the consent for both your organization, as well as the individual like Martin just mentioned, you can just withdraw consent on, on one thing and leave the other ones still standing. And what will happen is that scope will also change constantly. And these can be minor changes.
A requirement for every organization is to store consent, as well as to have an audit trail. Like when consent was given, when the scope was changed, et cetera, the individual may require needs, or even want a receipt of the consent for his or own administration to keep track of it.
Its purpose is to capture at the same time, both privacy policy applicable at that moment, as well as the purpose for sharing the personal information. So that's an important thing. It's a policy part and it's a purpose part.
And finally, the view of all the consents the individual has given to your organization that transparency needs to be given that's more or less mentioned also in the GDPR. And it will give the individual the possibility to review consent anytime, and to extend or withdraw consent anytime and easily. So when you give consent, it must be as easily to withdraw consent. Martin just mentioned in, in his slides and as a bonus, not a requirement, but as a bonus, one could consider to have the actual consent travel with the data. And by the, do I say that?
And it's because it's, it's one of the new concepts you see in data protection where security access policy travels with the data instead of the data stays in a central place and policies and access are more or less like a layer around it.
So that could also be a trend where things are going. As many of these conceptual building blocks for consent are new. There are standard efforts on the way the first specification that emerged was the consent received that I just touched. It was driven by Canara, which is a standardization committee.
And we know Canta from standard that done a lot more, but Uma is a interesting one to look at for this case, that protocol specifically allows individuals to control the sharing of their data or resources between different online services on that behalf. So there's an, an autonomous party involved basically to handle that. And in a way it's a, it's an exchange magazine based on consent for exchanging data between different legal parties. And contrary is also also the driving factor around standardization on consent management. And they likely start very soon with a new working group on that.
And we plan to be completely involved in that to give, because it's theory to give a bit of view of how crucial consent can be in practice, just to be compliant as an organization. I took an example with both PSD two and GDPR in it. So this is just an example of how things, how complex things can be. And PSD two, we didn't mention in a lot of details. So I'll tell something about it.
It stands for payment service directive, version two, in this case, it's also European union directive, like the GDPR and the idea behind it that European union had was that they wanted to open up the European financial markets to all kind of players, also new thing, deck players, and also from outside Europe. But to do that, these players will have to play the same rules according to the same set of standards.
So that makes sense. And therefore they made this PS PhD two directive for the current financial institution.
This means that they will get more competition and they will have to offer the possibility to disclose customer data to third parties if the customer itself requests. So, so it could as well be that the banker, you normally have your funds will have to exchange information with PayPal because you ask that to be done. And our many, many other things you can think of as advising you on where to, to invest in what funds or look at your pension, things like that.
One thing is sure, P two will stimulate an innovation boost between banks and FinTech companies going back to consent specifically PSD, as specific consent requirements. And one of the things is that third parties that receive payment information need to receive consent from the individual and financial institutions.
So banks need to have consent from the individual before they can exchange information. So basically that two consent. So you have to have a double consent before you can even do something and the services part.
And on top of that, the GDPR itself request the data control is to prove or demonstrate in a way that consent was given. So that means a kind of a record somewhere, both places that needs to take place. So looking at this, and I'm only looking at three parties now from the five players in the POC two, the top one is the account information service provider that will envision for the consumer its payments account data, likely from all financial institutions, here's a customer form, and it can do analytics for you, advise you on, on doing certain things.
So you basically use them as a service for financial advice on the bottom.
It's the payment initiate initiating. They all have these four letter ations service provider simply set. They can do payments for you and on the right it's the current known financial institution also known as your bank and you may have many. So all three have to get consent from the consumer, the, the data subject, and have to get it both for GDPR and P C two.
Then for GDPR, they also have to demonstrate to the consumer, to the individual that they have his or her consent, and the two service providers top and bottom need to pass the earlier given consent to the bank as they need to have the proof the consumer gave that consent also. So that double consent and the bank needs the consumer's consent on top of that. So that's even double double just to crosscheck, which they have to demonstrate back to the, to the consumer. I think this picture makes it pretty clear that there's a lot of interaction and administration to allow services to work.
There's a lot of interaction with the consumer. You do not want to be too disruptive, and you have to have a lot of places where you store consent and manage consent just to, to play a role in this, in this area of service.
And after all these consents are given, they can also be different policies applicable, like the time that consent is valid. And here you see to these specific two differences, the account information service provider can only use the consent access account data for 30 days that needs to get consent again.
So if you want to keep using that service, you need to basically resend after 30 days, the payment initiating service provider that does the payments for you will only have consent for data used for that actual payment. So consent has a purpose and it has a policy.
Now we saw how the consent flows go. It's not difficult to figure out that you need a user interface and you need APIs to play a key role in the, in this as to, as your website and your IM solution will be de communication channel to the communication, to in a non-intrusive way.
At least if you want to stay in business, ask for consent and manage consent, and that there is a need to keep consent and a purpose close to the specific data where it's applicable for. So you can let it travel with if one of the applications is requesting it or needs to request it from the individual itself. In this picture, you see how our welcomes stores and disclose consent and how the different build building blocks fall into place. On the top, we have the stories of the consent sets to the data items itself.
In this case, it's birthdate in the yellow bar, which is like the customer record. And we store that consent in metadata. As there can be many, many consents and purposes on one data, it item, and a consumer will have the ability to just withdraw one of these consent on that specific in this case date of birth. So that's why we put it into metadata and we put the consent multi value into that. Then on API level, that's a, a nice green buy in the middle. You have two important API blocks. You have many with these two are relevant.
The one covering the profile information, giving the transparency to the consents given as well as the personal information you store and process, and one covering all aspects of consent, the consent API, and some of the building blocks are more user interface related. So the view one is really one that you want to have in the UIUX.
Also, if you look at the data transport requirement from the GDPR will also be a view in the XML file or machine readable file that people can extract from the, from your system. And the other ones are more API driven, although they can also have a user interface, but definitely API enabled capabilities. And this is where your business processes and your applications linked into the identity management platform. And they use consent lifecycle capabilities, the receipt itself, we're not using currently the receipt. We will be doing that as we will follow standards.
And hopefully we'll contribute also to those, but that's what what's the setup is. And then to touch the one that I saw as additional idea is that then travels with the, with the data in this case, it can, so you have a front door, which is like semi ID connect O out where applications can get the metadata sent into an assertion or J web token.
Then you have the back door at the end where we have restful API service. So where you can ask for the consent on a certain item, you can write a consent if you get it from your own application, things like that.
So that from doors and back doors, ways to get to the, to the system and this way you can basically travel or the, the consent itself can travel in the package with the attributes towards the application itself. And that's pretty powerful thing. So if you look, look at cm solution, and there are couple of ecosystems in every business that can play a role like a CRM system, but we think that cm system can be play a very important role in constant lifecycle management and can become the authoritative source, basically for both information around the consumer.
They can change also and extract export that is transparent so they can see it.
And also for the consents that also needs to be transparent.
So it's, it's not a very unlikely place to store it. It's likely next to CRM. The one that most organizations will look at it, CRM systems are often not opened up for the customer or consumers itself. So that's a little bigger challenge then to end. And this is not a bombshell slide, but what I often hear and too often maybe is that you can bypass consent by just changing the terms of service and the privacy policy of the service. And Martin already mentioned it, that freely given thing.
So I wanted to, to make a reminder that the GDPR is very clear that you, you can't ask additional information like a ate from the consumer, if that's not necessary to fulfill the service. So you can't make it mandatory, that will be illegal. So asking a birthdate and that you don't actually need to perform the service and not allow them to enter your service unless they do enter that thing, their ate that's against C DPI.
You need to ask consent in that case. And they are allowed not to give that to you and still get your service.
So this is where you have to find that non-intrusive way to ask consent, to make clear to the consumer, that it will have business benefits for them or personal benefits for them. And then they likely are going to give you that consent. So you can use the information all legal and, and all it's it's glory within the purpose that the consent was given and use it to drive your business. And as competition may not be doing that, that can be a business advantage. So that was my last slide. That was from my point, hopefully it was useful for the people attending.
And I'm curious about the questions and with consent back to you, Martin,
Thank you, Carney. So let's directly move to the Q and a session. So if there are any questions, just enter them. So the first one I have here is are there any requirements and standards to protect on rests and during communication, the consent given per attributes cared that fully got a question. So I think it's basically, okay, great. I'll leave it to you.
Yeah. Yeah.
So if, if you look at how that is sent, then it's always sent with appointed to the individual itself in a way, shape or form. So it's very likely that in that package where the consent is, there is an attribute, but there's also a reference to the user. So that package itself becomes PII information. And if that's not protected well and comes in the open is breaching a way shape or form, then that will be a breach. So I think that answers your question.
If you protect the consent with a, a pointer, and that pointer is in a kind of a database that only you as an organization has, so you tokenize it like it's done with credit card information and then TCI purposes, then you could maybe stay away from it, but it's too easy to encrypt things. So I don't see that used very often then.
Okay. Hopefully
That's, that's clear, so I will protect it. And there is a requirement for it if, unless you,
Okay, next question. What kind of proof needs to be there for consent? So it's an audit file enough.
Yeah.
In a way, an audit file, you need to have basically a record. So proof that the consent has been given, which means that you need to know the individual. So you need to have a record on that. So if it's online, you need to have a record of that. The user was locked in, then you need to have a time. And because if there's any discussion in, in court, it's also good to have a time stamp. So has the time with the, with the certificate. So it's a hundred percent certain that that event has taken place and was recorded at that time block block, go to court. That's not,
Yeah.
Blockchains might be a good way too. Solve challenges.
Yeah. If you have a lot of people that have a lot of knowledge about blockchain, Martin, then that's a good option.
Yeah, I agree. Okay.
Okay. Then another question I have here are there standards for notifying online services that a content has been withdrawn? So can the, can a consumer identity management solution do that to provided information? Maybe I start and then you continue currently.
So, so, so one of the things which is very clear is that the online service, first of all, is responsible for being compliant with the GDPR. So the question only is, does he do it himself or does he rely on an additional tool? And then we end up with the standard question does need to do a proprietary integration or is there a standard, but at the end, it's really, first of all, the data processor and the related. So it's not a data's abstract and another, some service. It's really the one who is processing the data who is responsible to remain compliant to reregulation coronary.
I think you probably have a lot to add to this.
Yeah. Because the one that it, it depends on how many parties are involved. Let's say there there's only one party involved and there is a, a service that is using that information. Then it's maybe better just to store information centrally and store the consent with it and let specific application of service on the fly request that information, because then the consent can travel with it. And it would immediately know the exact status of the consent.
The other way of handling is that third part is you, of course have the consent receipt that you may use. You may be able to use it, or you can be using API scores just to check if the, the consent is there. And on that last one, there is a standard, or there will be a standardization effort on the consent receipt. There is already a standard where you can request through an API, the consent received, and that's a standard, right? In a way it's been set up. So you can read as a consent applicable.
So there, there are a few ways of, of looking at this, depending on there are multiple parties in the ecosystem or just one company.
Okay. Another question which came in is when a data subject requests, its records to be deleted, what to do with the content audit trail. If that audit trail is deleted completely, all evidence of content is lost. So it's probably a tricky question. I think it's,
You
Have simple answer,
I would say no.
Yeah, because simple answer, because in the GDPR, they, they say that you have the ability to basically ask your data to be removed, but there are some exceptions and that's quite a nice list. And one of the except exceptions is if there's a legal ground, not to remove it. So if you from a new director need to keep track of these consents, then you have that specific rule in the GDPR to communicate back to the consumer, that you will not remove that, that audit bill on this consents because of the law.
So you don't have to,
But, but, but if there's not the law, which says you need to keep the consent information, then I, I don't think that there's, there's a law, which says you need to keep the consent information when you delete that information. That might be somewhere in the gray area.
Yeah. Be because you still have to have that consent record because there is a time that you use that consent to do something processing of certain data. And the consumer itself can later say, Hey, you were not allowed to do that. And then you can't protect yourself. Yeah.
So,
Okay. Yeah. I would say potentially, I think most likely you should be able to, to keep it, but I think that's the question. Yeah.
That, which has to be left the lawyers at the end,
It's definitely gray area where legal people will have an opinion on, and I would follow the legal people now first because of, you don't know what will come out of any court cases in the future.
Exactly.
And, but, but I think the point you cornet brought up again, ISS very important. If there's another law, which says you have to keep records. So for instance, if you did financial transactions with your customer, the records about these financial transactions have to be kept while other parts of the PII you have might be deleted in that case.
Yeah. Right.
Okay. Another question I have here, will consumers not get cookie crazy with all these consent questions? Will they not just go blind and click a approve on all requests? Like we saw with the cookie law.
I personally may bring in my, my opinion here. I, I personally believe it's consent for purpose. We will see more people starting to think about what they, they really give consent for. So I think it'll will change a little,
They will get used to it. But in the beginning, I, I, I was thinking of putting a slide on that one because I have that worry to it.
If you have too many consent questions and these are not done in a proper way, like communication department has not looked very well to the way you asked that question or pop it up at the right moment, then that could be like really annoying. Like the cookie legislation was, or is still, and we have to be careful with that because then people will click, like they will become blind because they find it annoying and they will care later, but there's no later they have to decide then. So that's yeah.
It's, it's rule C in practice and it will really depend on how the larger organization that have a much better communication departments often tackle this because many will copy that way.
Yeah. Yeah.
You know, I can imagine that people and say, Hey, why should I click all this stuff? And then only click sort of the minimum instead of click everything. I think that's that's. So it really might reduce the, the amount of content you give, you get compared to the, the age of cookies. So to speak you, large organizations might be better able to figure these things out. I have another question here, how can small small organizations handle this? They might not have the opportunity or bachelors to, to really do it.
So how, how can they do it?
Yeah.
So, so is there a light light version to do it? Well, it depends on which brands they are. So if they stay away from the PSD too, because you saw that was quite complex, then it's, it's, it's easier for them, for them to do a lot of the GDPR things you can do with paper process things. You only have a problem where you have a lot of consumers and small organizations often don't have really crazy amount of consumers, but if it's around consent, then I'm afraid it will be like these stick boxes consent that you will see.
And hopefully we will see nicer viewed or nicer examples of it and plugins you can put in WordPress or whatever you're using to make your, your eBusiness platform that will make things more easy. But in the beginning, I think it's gonna be like quite tick box kind of exercise and not very nice to manage. I'm afraid of that.
Yeah.
Wait, wait and see, I have another question here. Are there IM packages, which is PR functionally right. Available as right. Available as described during the session. So I think clearly Corona will talk about this.
Maybe let, let me start with the answer. Yes, there are. First of all, second, there is for instance, equipping a co-leadership compass on the consumer identity management solutions, which also covers the GDPR support. And so yes, there are solutions and there are also organizations which can help you like finding the right one. So
I only agree with, yeah, I can only agree with that. I think we started about one and a half years ago with the topic as European party. We thought this, we could not pass this or pick this up later. This was really our topic. We saw it like that.
And most of our competitors were from the us. I think that was wise because it take takes quite a while before you, you can manage this in a proper way and before you can build it into your product in a proper way.
So yeah, we are available on this part. Others are definitely on, on the way. Maybe also available. Martin can tell more about that, but at least we started, I think, as the first one.
Okay. So I think we are guns through all the questions right now with step. Thank you very much to the antenna for listening to this, copying our call webinar. Thank you carne for all the information you delivered and hope to have you back soon in one of our other upcoming webinars or at one of our conferences. Thank you very much.
