Well, good morning, good afternoon, or good evening, depending on where you are in the world. And welcome to this KuppingerCole webinar supported by ping identity. This webinar is on GDPR and the six critical steps to compliance and brand differentiation. I'm Mike Small. And my co-presenter today is Matt Classon. I'm from ping identity, Mike Small. I'm a senior Analyst with Coco and MacLain is a director of product management at ping identity. So to look at the, the details of this, this webinar KuppingerCole is an Analyst company.
We specialize in the issues of security and compliance with a specialty in the area of identity and access management. And we provide research services for our clients, our end users, and also for vendors, we provide advisory services and we also run events. And some of the events that are coming up are in, in, in Paris. We we've very shortly got consumer identity world tour in Paris, which is then moving on to Singapore in December next February, there's digital finance world.
And of course in may, as there has been for the last many years, there is the European identity in cloud conference in Munich.
So as regards to the webinar, everyone is muted centrally. This me is being recorded and the recording will definitely be available tomorrow. If you have any questions during the webinar, you will find that there is a tool that is part of the, the go to webinar that will allow you to ask questions. As we are going along, I will be monitoring the questions that are asked. And at the end, we will try to answer those questions.
And if we can't answer them, then perhaps we'll try and get back to you after the event. So the way we're going to organize this, we is that it will start off with myself talking about the six critical steps that everyone needs to take in order to ensure complaints. And this will be followed by a set of presentation by Matt PLA to discuss how customer IAM solutions can not only help you meet GDPR compliance, but also deliver a better digital experience for you and your customers.
So going onto GDPR, the GDPR challenge is that when this comes into force, will you be ready to meet it?
And there are increasing numbers of surveys that I have read that describe how many organizations haven't heard of it still, even in some large organizations there, the board has not been informed that they need to do something. So to give you some background as to all of this, this is the result of many years of evolution of privacy legislation within Europe. It was adopted by the EU parliament in May, 2016. And it will apply to all EU members from May, 2018 and this regulation, which is different to what was previously a directive. This regulation applies consistently to all of them.
And that is one of the reasons why the regulation was brought in, in this form was because of the variety of approaches that had been taken by the different member states.
Now, this is different to the current legislation in a couple of ways. First of all, it applies to both data controllers and data processes and data controller and data processes are technical terms in the law where the data controller is the organization that collects data for a purpose. And the data processor may be the same organization.
But if the processing of data is outsourced to a cloud service, for example, then the data processor has different responsibilities. However, this new regulation applies to any controller and any processor wherever they are. And whereas in the past, the regulation was only had a scope. Only that the directors had a scope only within the EU. It now applies everywhere.
And so if you are a us based or a, a Chinese based or an Australia based processor that is processing a personally identifiable information about a living human being who happens to be at that point in time, anywhere within the EU, this regulation applies to you.
Now, the G DPR, the general data protection regulation has six, three key principles. And these are described in various articles, but the key principles are that the information must be processed fairly and lawfully.
What that means we will talk about a little later on, but basically part of it is that it is for specified explicit and legitimate purposes. So you can't process it without there being a good reason for you to process it. What the data that you gather should be adequate and relevant, but should also be the minimum that is necessary. So you can't gather lots of information in the hope that it might be useful. You must only have the minimum that is really necessary. It must be accurate, and it must be kept up to date.
So that's important, especially if you have legacy information, but it also must be kept up to date.
So if things change, then you, you need to keep it up to date.
But if, if, if you do keep it, you should keep it no longer than is necessary. So if you simply have gathered the information necessary to deliver a parcel, then that information should not be kept for longer than he's needed to deliver that parcel. And to be sure that it was delivered correctly. If you've got a product that has a guarantee, then it's fair to keep it for. As long as that guarantee may, may enjoy.
Now, one of the key things at the end of all of this is that the data controller is responsible and liable to ensure and to demonstrate compliance. Now, what this is doing is this is putting the burden of proof onto the controller for anything that happens. So that means that if you have a dispute with the data subject, it's not up to the data subject to prove that you did it wrong, it's up to you, the processor or the controller to prove that you did it right now.
Personal data is an interesting thing because personal data is quite specifically defined in the articles and the regulation.
And this includes because there are specific re references to things like an identification number in Japan. It's the, your number in the EU or in the UK. It's my national insurance number or my health number and things like that. It's your location? What identifies your location, your online identifier for your example, your email address or anything, and anything else that's specific to the physical genetic or economic cultural or social identity of the person.
And there is a specific definition of what is called sensitive data and that sensitive data covers things like race, political opinions, religion, or beliefs. Now it doesn't say that you, you, you cannot absolutely hold any of that, but if you do hold it, you have to have it for a good reason and you have to give extra protection to it.
So lawful processing is basically for most cases, it is to do with the fact that the data subject has given consent. And that is one of the, the big things that we're going to talk about as that you need to plan for.
It also could be necessary because you have a contract and you need to have this information to fulfill the contract or to comply with some legal obligations. So there may be reasons why an organization needs to keep this information, because there is a legal obligation to do with this.
It, it it's possible for information to be collected, to protect your vital interests. So if you are ill, then that allows the medical profession to hold information about your illness without necessarily you having given consent. And there can also be a lot of legitimate interests and for historical statistical or scientific research. So you need to be sure that you understand if you are collecting or processing information where that information fits in all of this.
Now, having looked at this, a lot of people have said, how, how a problem this is going to cause, well, in fact, he's actually going to create some opportunities and benefits. So in the past, because of the geo jurisdiction, cha differences between different jurisdictions, that some companies in some parts of the world would have an unfair advantage. This is intended to level that playing field. It also clarifies what consent means and how you should obtain consent so that you can actually end up with a, a more trusted relationship.
And finally, it gives you a chance to get a grip on and to sort out and to, shall we say, scrub and sanitize the data that you actually hold to make sure it's still relevant and that it is correct.
So in terms of an action plan, we and co have identified six specific things that any organization should be doing. And these things start off with the question of discovering the data that you actually currently hold.
And you may say that this is something that's quite obvious, but I, I have found that the majority of organizations that I speak to have difficulty in finding all of this information to give you an example, that I was talking only recently to an auditor who was going around the European subsidiaries of the organization that he worked for. And each one had its own database and its own special collection of personally identifiable information. And that was causing considerable difficulty.
So you need to know what you've got, where is held, where it has been copied to, if you are going to continue to hold it, you need to have proof of why it is you are holding it and what consent you have, and you need to have checked, whether it is accurate and up to date.
Now, there are different kinds of tools that are available to help with this. Some of them are in the nature of data leak prevention tools that simply allow you to say this could be sensitive data, but they don't necessarily find all the information that you need to know.
And when you have got it, you need to be able to have some kind of a, an inventory of what you have and why you have it. The worst thing is just to have loads of spreadsheets with email lists in them, nobody knows where they came from, what they were used for, how consent was given.
Once you have found this data, you actually need to take control of it.
And so, because the data can only be used in specified ways, how can you be sure that the data you hold is only being used and disseminated in those ways? And this boils down to having some kind of an understanding of what policies you currently have, review the policies and review the existing systems and implement some form of access governance to be able to define and control how access to this is is controlled.
And to make sure that that covers not only the structured data in applications like CRM systems, but also all of these potentially unstructured things like lists of, of email addresses in spreadsheets and so forth. And to make sure that all of this is being done in accordance with consent, that that's going to be a big challenge.
And not only that, but you have the other problem to do with aggregation that the, the use of big data tools, for example, to be able to draw together, lots of fragments of information could be problematic if you didn't have consent at the end of all of that.
And remember that some of this unstructured data may well be things like telephone calls. It may well be images, video, CCTV, and other things like that, not just the spreadsheets when you've found this. And you start to ask yourself about the question of consent, then the lawyers will have lots of things to say to you about how you can ask for consent, what text you have to use and so forth.
So you obviously have to take action to make sure that your systems are in fact correctly collecting consent, but what you, what you are, what you are now doing is you are, you are introducing a new set of challenges around how can you identify the data subject.
I'm sure that like many people, I have multiple personas. So how do you know which the person is?
And if, if you get consent for one of those personas, does it apply to another persona, for example, and ultimately you need to be able to have a strong link between an element of PII data that you hold and that consent potentially on a field by field person, by person, person by person system. And one of the interesting issues to me is that many organizations already have identity entitlement systems that, that are governed by a management approval process. What you are moving to with GDPR is a use of PII data that is being controlled by the consent of the individual.
So you need ultimately to have some kind of a linking between your access control systems and the, the consumer, the, the person who who's data, the data subject, you are holding the data for so that they can do this.
Now, in addition to that, you also have the problem of being able to fulfill subject access requests. And also the question of return of data, subject access requests. Anyone has a right to ask an organization to just holding data about them, to see a copy of the data that they hold.
And the return of data is that if in fact your you've got some data being held by a service provider, you should be able to request that data be returned in a usable form. Now, cloud is a, a, a big question.
If you, if you've gone through the first three steps, I'm sure you will have found that some of the data will have found its way into the cloud, but do you have a policy that says which cloud services people can put data in within your organization? How, how can you actually be sure that you've found all the data that's gone there?
And once it has been uploaded to the cloud, is it being held in a way in which the cloud provider realizes and accepts that they have a responsibility to protect that data and to help you to implement your OB obligations under the GDPR, for example, is the data being held in a location that is acceptable to the, to, to, to, to the laws that concern that particular data subject. Now, one of the issues is how can you get a cloud provider to tell you that they're doing the right thing? And most of the cloud providers have various certifications and codes of conduct.
So there's a couple of codes of conducts that have come up in the recent years. And many cloud providers conform with one or the other of these. Ultimately, you need to do the research to understand what, what standards apply and how they matter.
When a clamp service provider says we've got a, an SAS 16 SOC two report, what does it mean for you? If they say that ISO 27,018 conformant or 27,017 conformant, what does it mean for you? You need to use these third party certifications, but you need to understand what they mean.
And from your perspective, you are constantly have to ask yourself if I am asked difficult questions by the regulator, how am I going to be able to prove that I'm compliant okay. Much has been made about data breaches. And there are many tools and techniques that are out there selling you how to manage or avoid data breaches, but every organization should have a process for managing a data breach. And if you don't have one and you haven't tested it, you are in trouble because your managing director, your CEO is not going to be at all happy.
If they turn up to work on a Monday morning and find sky TV, sat outside their head office with report reporters, wanting to interview them about what they're doing about the fact that they just lost all their customers data. You need to have a process. You need to test it. You need to then look to see whether it complies with GDPR in particular, to do with things like notification of the, the regulators and notification of the data subjects that are affected. And remember you are going to have to prove that you are compliant.
And finally, there is the question of data protection, and there's a couple of things here. One is that any organization of any reasonable size needs to have appointed a data protection officer, this can actually be provided by an external consultant. If you haven't done one, you, you should have one appointed.
Now, if you are in the it department, the data protection officer is going to be your best friend, because they're going to help you to understand what it is you need to do. You may need to perform data protection, impact assessments. You need to find out where this is relevant, particularly if you're holding sensitive data and make sure you have the wherewithal and the tools to help you to do this. And finally look at things like privacy by design and default, and make sure your plan includes where you're going to implement this.
So in summary, proper planning for GDPR will prevent pain and penalties. And to put a kind of more concrete feeling on this for access governance, which is an important area, you can only control what you can, you know, you have, and what you know, you have, you have to have classified so that you can see which of all this data you're holding is personally identifiable information.
You need to take control of that data. And that invariably means identity and access management. That consent is about customer identity and customer controls over the iden over the data.
So this takes you into the area of CRM systems and customer identity and access management systems using the cloud. You, there are tools here like cloud access, security brokers, and various DLP tools that can help you to know what you have in the cloud and to control what can go to the cloud.
And from a point of view of data breach, then encryption is a good tool to help you to say, if it is lost, it's, it's difficult for anybody to work out what it meant, but monitoring of activity using for, for example, user and entity behavior analytics is another key technique for realizing that you actually have had a data breach. So this is my part of the presentation. And with that, I'm going to hand over to Matt CLA from ping identity. Who's going to discuss what ping can do to help with this. So over to you, Matt.
Great. Thank you so much, Mike. That was awesome.
Thanks everybody for attending and for your time today. So for this important topic, and Mike did a fantastic job of framing up some of the key requirements of GDPR and even doing a mapping back to identity and access management and some of the related technologies. And so I'm just gonna go a little bit further into this topic of customer identity and access management and how it helps solve the GDPR challenge.
So the first question really to ask as an organization is what is your business goal?
If is your business goal simply compliance full stop, nothing else, nothing beyond you simply want to comply to the letter of law, check the compliance box and move on. Typically that's not the case. Most of the time organizations as they, you know, obviously that's a minimum bar they have to achieve is compliance with GDPR.
But many times organizations realize that, you know, as they think about how they're going to implement a solution for compliance, they realize there's a lot of decisions to make as they do those discovery phases that Mike talked about in terms of discovering, where is this information, right? Where is this, this PII? Where is this personal information for EU citizens?
What systems contain it, what data stores contain at, they realize that what they have in essence is going to be hard to simply take as is systems and slap compliance on top, because what they discover is that their systems aren't optimal.
They're not optimal for a lot of reasons, but, but one of the, one of the areas that they're not optimal in is how their view of the customer do they have a single view of the customer?
Are they able to interact with that customer, understand data and analytics, not just for compliance, but to actually use, to actually help the customer have a better experience as they interact with your brand as your, with your company.
And, and, and what they discover is that there's a better potential architecture and customer identity and access management can potentially help them not only comply, but turn in essence, this challenge of GDPR, this compliance standard or regulatory need into an opportunity to build further trust with their customers, engage better with their customers and sort of just move beyond simply compliance. So that's, that's really what I would challenge you guys to sort of think about in the context of, of this presentation.
So this was a report done actually a couple of years ago by Aberdeen.
And basically I think it's really good. It's it's basically says I am is for everyone, right? And this is part of an infographic that they put out, but what they, what some of the key findings of this report in the study show that I am is clearly a business enabler. So I'm gonna show you how it can help you comply, which is with GDPR, but you really need to think about it as, as, as more than that as, as an enabler to your business. And so these are some of the key statistics in terms of improving productivity, improving user satisfaction, and is viewed right as, as, as an enabling system.
So KuppingerCole of course produces a lot of really good materials. This material that you just saw from Mike and some of their other materials on GDPR is, is excellent. They also have reports and a leadership compass on customer identity and access management. And they specify in their report that they, as they look at vendors, as they look at solutions, they're looking at several different requirements or areas or capabilities. And so those are listed on the left of this little graph on the right is what I've done is basically mapped these two GDPR.
And this is somewhat subjective, but in terms of their applicability, in this case, I just use two ratings strong or medium in terms of its mapping. So you could argue that maybe marketing or some of the probably marketing is the one you could say is maybe even weak in this case, I just ranked as medium.
But if we take those sort of from top to bottom, if these are the requirements, if you will, or capabilities that you would evaluate if for customer identity, access management, these things of course apply, right? So there's obvious ones like consent.
So consent consent management is something that a, a good customer identity access management solution should have as part of that solution. It should provide control for the users as to manage their privacy settings. It should allow you to capture consent. It should be auditable and so forth. It's important. But when you think about that action of consent, how do you know that Bob is really Bob when Bob is consenting to that information?
Well, that's where authentication comes in. So authentication becomes a really actually important ingredient in any of these compliance standards. You need to be able to make sure you understand who Bob is.
You need to be able to do that in a seamless manner, and you probably need to move beyond simply passwords to provide that authentication. And so that's why I say that's authentication and of itself is a strong requirement. It also is a strong requirement because that's how you're gonna protect those systems, right?
From a data security perspective, mobile is important because we have to of course, protect across all channels. We can't just do this for web applications. We have to make sure that we are compliant and we have good authentication. We're again, doing, providing that, that same technology, that same ability, that seamless ability for them to customers to manage a profile in a mobile registration in this case, the way, the way KuppingerCole defines registration, it includes profile management.
So self-service management of a user profile, which is a big part of GDPR when you think about data access and rectification requirements.
And so, so those things are very, very strong mappings.
And if, if you can do those well again, looking, this is again, focusing on consumer data, then you're gonna be in, in, in much better shape when it comes to GDPR compliance. So, so let's take a look at then at, at how we define our customer identity access management solution at ping on the right. These are all capabilities, and these are, again, has nothing to do. This slide is a slide we produce independent of this presentation. This is just a slide to describing the capabilities.
And you'll see a strong mapping between these capabilities and Kuppinger Kohl's definition of the capabilities they're looking for that a, that a comprehensive customer identity access management system would have single sign on across digital properties. So that's authentication, MFA and transaction approvals that goes beyond simple password based, single sign on or authentication to add additional factors.
But also there's some interesting things you can do with transaction approvals that can relate to consent.
So we can, we can kind of with, with a customer, we want this to be very, very seamless, and we'll, we'll show this and we'll show how, how we've implemented this capability, such that it's more, it goes beyond just simply multi-factor authentication to help you with consent and help it to be very seamless, governing control, access to data. It's very, very critical, right? That's pretty obvious that one maps directly to GDPR as well. We'll talk about that a little bit more detail, unify profiles and sync data platforms.
So this is, is the big one, because at the end of the day, when you do your analysis and discovery phase on where your data is, you're probably gonna discover you have data all over the place and how do you gain control?
And so one strategy that many of our customers are implementing is a strategy where they implement our data store as the single authority for, you know, both synchronization. So unification, synchronization, and virtualization of that data.
And then they put controls a governance and controls over that data store and they start transforming the way they do business, such that store all structured data. Eventually many organizations start eliminating some of those other data stores. In some cases, that's not possible cause of the system's in place, but they still have that single view of their customer. And they have a single place which they can share data, but govern how that data is shared, audit the sharing of that data and so forth. And at same data stores where we can manage consent, we can manage it's all auditable.
And so this unification and synchronization is very important. Managing preferences and privacy of course, gives that control back to the users and then end to end security meaning whether the data is during collection during, at rest, during in transit, that it is encrypted. It is stored in a highly secure manner. And then of course, when we're dealing with consumers, many times, we're dealing with millions of users and we have customers that have in the hundreds of millions of users.
And, and so being able to scale and perform at that level from a data store perspective is, is really important.
So again, these five bullets, I think there's huge applicability to GDPR.
Again, I'm not suggesting that that customer identity access management is some turnkey, automatic compliance at all. I'm simply saying these capabilities help you in your overall compliance approach and solution. So let's talk about these, these capabilities in a little more detail, so capture and manage consent. So first of all, this has to be done across channels. We have to support this across channels. It has to be a simple experience.
We, in order to garner trust, we have to also make sure customers enjoy the experience as they interact with the brand. We have to have attribute level control. What that means is this is this unbundled consent required. It has to be all of this consent has to be logged for audit purposes. It has to comply with not only GDPR regulations, but other regulations.
And so we have to have different levels of policy around that consent to be able to categorize that consent.
And then ultimately we need to provide self-service management of those privacy settings and consent to the customer so they can change those settings later. If they give consent, they have to be able to remove consent, right. And retract that.
And, and so this, this applies specifically to articles seven and eight, most applicably to most directly, I'm sorry, from a GDPR GDPR perspective, but has some applicability to article 13 as well. So I talked about some innovative technology here in terms of how you may think about change, the way you think about how we can gain consent. And how does that integrate from authentication perspective as you're, as you're gaining consent and improving the way in which you authenticate and gain consent. So we've implemented something called or, or released something called the ping ID SDK.
So we have a solution it's a cloud service called ping ID. The cloud service now has the ability to integrate within your native mobile applications.
So you, as a company, as you roll out native mobile applications to your customers, it may make sense to include some functionality like I'm about to show you. So for instance, in this case, this is, this isn't really directly a consent use case. You can see that there is some applicability, but in this case, this is a shopping cart, but you can apply this in any way. You'd like in this case, a customer is shopping. They submit they, they submit this transaction.
And at that point, because it's maybe above a certain, certain threshold, whatever the company's policy is, again, if this is a, if this are doing some action here where you're gonna gather data that that needs consent, this transaction approval, we could, you can simply change the name of this or the words in here and say, you know, consent approval sent to trust a device.
And so now they will receive a push notification, not in a ping application, but they would, they would actually, this would be built natively into your application, such that it is basically expecting push secure push notifications from a cloud based service, which actually gets routed through the mobile carrier to the device. And you can supply information in that push notifications, such as specifics about what they're approving or what they're consenting to. And they can simply use their fingerprint to actually approve or consent, give their consent.
Or of course they can deny that because it wasn't really them. So in one step we can both authenticate the user and gain consent and it's audible. And so we can do that through a really good experience for a mobile device. So once they give their fingerprint, of course, then it's approved. All right? So let's move on customer self-manage profile.
So once we're gathering this information, we start gathering information about the user they become from an independent or anonymous shopping, you know, somebody who's shopping on your site or browsing your site.
And again, that's when sort of the consent cycle or life cycle sort of begins to, to a known user. Once we gather the consent based upon personally identifiable information, that's when the cycle of being able to manage it. And so customer identity, access management systems, as you gather that data and build that profile, put that control right back in the hands of the consumer. And there's actually a huge benefit to this. Not only is there benefit from a GDPR perspective, now they can actually manage that information you're collecting.
They can, you're actually inviting your customer to give you more information that's applicable to them. And by definition in that cycle, you're gaining consent from them to gather that information, they're giving it to you voluntarily.
We can audit all of those transactions and he changes to this profile, and then they can also modify, and or this is where they could, you know, set their privacy settings and so forth. All of that is part of this.
What that does is it actually allows you again, to engage with your customer more closely or intimately to allow them a, a really good experience where they feel they're in control, they're gonna fosters trust of your brand and so forth. And so this account profile management is really important aspect, data, access governance. So now we've collected the data. We have a profile, they can manage the data. We can gather that consent data. So we have to now manage right how we share the data who has access to the data.
And so we have a data governance capability or layer, which sits on top of the data store.
And it's actually very sophisticated. It allows you to create policies, regional policies, industry policies, consent, and privacy policies and, and application specific policies, any type of policy. And many of those can be created automatically on the fly. So as the user is giving consent that unbundled consent, we can actually write policies automatically that then govern how that data might be stored, sorry, shared from any application that touches or wants queries, that database, the data store.
And so here in, in here's an example where we have different policies. So the total amount number amount of, of data being collected is in this case, this is a very simple example, is name, social security number or social insurance number or whatever it might be in your country, credit card, number preferences, date of birth in all of these cases. So that's the full amount of data being collected.
Now, policy is gonna dictate depending upon the individual application, which policies actually are kicked in. It's gonna dictate what actually is, is shared or shown or given access to an individual. So on the left, we have two policies, which in essence, start hiding if you will, or obscuring data. And actually don't by policy, don't allow those, that data to be, to be shown right, or to be shared, or to be returned in this case.
So in the, on the left social security and credit card numbers is, is not shown on the right. There's an additional policy, which not only takes out the social security number and credit card, but there's an additional policy which kicks in which removes the date of birth and so and so forth. You can see how you can set up policies to govern access to the data, which in turn, of course is part of compliance.
And by the way, these green numbers indicate the article numbers within GDPR, that these capabilities apply to.
Again, I'm not suggesting it's turnkey, compliance by implementing these features, but it is a help in your overall compliance solution. Another very, very important aspect. And this isn't just for GDPR, this is actually, there's a lot of other applicable com regulations that apply here, regulatory that apply, which is some other capabilities that are important in managing a global name space. So you have customers across the globe. So for instance, data residency, this is a big one. So where is the data being stored?
Can you prove that European data is being stored in a European data center within the EU? We can do that.
We can, we can take our data store and we can create partitions of that data globally, ensuring that as you implement those partitions, those instances, that there's policy, which states which data is stored in which physical data store, we can then implement synchronization across those data stores, both virtually and physically, and then, but also by policy not share certain information. So for instance, if European data should be stored and not synchronized to the us data store, you know, certain data, certain data can certain data can't. We can ensure that as well.
And then again, that data governance applies. Those policies apply across that entire set. It looks like one single data store from a governance perspective so that we can apply those policies globally,
Data securities extremely important. So not only the ability to have a flexible data store with that governance layer, but how is it stored? How is it stored a capture while it's in transit at rest, during replication in logs and so forth. And so we take this very seriously. This was designed and engineered for this very purpose of containing per personal information that needs to be secure.
And so there's a whole lot of features I'm not gonna read, but, but it is very important and is part of our solution. And then finally, again, this, the synchronization and consolidation of identity data included in our solution, but should be included in any is the ability to create those unified customer profiles by synchronizing data across multiple silos, to, to map data, schema and attributes, to do bidirectional sync, if necessary and support a whole lot of different connection methods and protocols.
So it's flexible for a diverse enterprise also, by the way, this one, this capability because of the synchronization capability could actually be extremely important in portability requirements for GDPR. So port portability in GDPR states that of course, a EU citizen, a data subject can request their data that you give it to them. Now what's required. What's interesting is it's required.
It's a, it's a commonly used machine readable format. That's one thing too. They can actually request that you transfer the data to a third party as applicable. And so that, that portability of data, this capability can be extremely helpful in, in supporting that again, to talk a little bit about KuppingerCole. So they have, of course, like I, I mentioned leadership compass P identity is a product leader in their leadership compass for customer identity, access management.
And again, just kind of summarize customer identity access management has a lot of benefits. Customer experience is probably the chief benefit, but privacy end insecurity, scale and performance and adaptability are all extremely important benefits for your organization that you could realize with a solution like this. And with that, I think it's time for, for Q and a.
Okay, thank you, Matt. That was a very interesting presentation. Now we come to the area to do with questions and I've already received a question from the participants through the tool, and I'm going to start off by looking at this question, because I think it's really a very interesting one. And it says, how do you ensure that PII is kept no longer than necessary? Couldn't a new use be found later on. And secondly, how do you completely delete data when in fact is no longer required?
So that's a very interesting question because in a way, the whole point about this, this regulation is to try and stop organizations from just holding onto data, because they might think of something useful for it later on the whole point about this is that if you give your data to an organization, you are giving it for a specific purpose, not for something that they might find useful many years later.
And so the, the, when you, when you think of the reason when you decide the reason for why you collect data, part of that policy should in fact include how long you consider that data to be valid for. So for example, if I buy a vacuum cleaner, I may say, well, I want to be able to buy parts for this to support it for the life of that vacuum cleaner.
And you, as the designer may say, the manufacturer may say, well, vacuum cleaners last five years. So we will keep your data for five years. And if you don't tell us otherwise at the end of five years, it will be deleted. You can't just hold onto it in the case that, well, maybe you'll buy another vacuum cleaner and so forth. If I buy another one, I'll have to come along and deal with that.
Now, when in fact it comes to the question of deletion, that is a really thorny problem because some database systems don't actually delete data. What they do is they remove the index to it. So this is an area that's going to be open for a lot of interesting discussion at the technology level, but the, you, you have to say, I have deleted the data. Then the question also comes up as to do with backups.
So if you have a whole series of backups that have been held there, what, what, what mitigating controls do you have in place to make sure that deleted data is secured and will not be reused later on? So you're going to have to think about all of those kinds of, of, of issues now in terms of what, what what's been going on, what, what the presentation by Matt covered. I I'd just be interested to ask the question to Matt.
Is, is this just a cloud solution or are you able to provide it in any other way and how, how is the product structured? What parts make it up,
Matt?
Yeah, sure, sure. So actually, and what I'll do is I'll, I'll answer that question and I'd like to comment on, on the question you answered a little bit from, from how we sort of have, have seen customers solving that from an architectural perspective.
But so, so our solution is, is, is in essence, it, it, it matches the enterprise enterprise. It, these days is hybrid it the way we view it. And so hybrid, it simply means you may have on-prem on premises applications in your own data center that you may house and, and data stores. You may have an I as environment, maybe an AWS or some other cloud environment in which you are housing again, your enterprise applications that you configure install and maintain, but in a cloud environment. And then of course you may be using SAS space applications, which are services.
And in essence, that's our solution.
So our platform is we call it, I am anywhere you can install.
Certain components are, are restricted, and which of those environments they work, but many of the components can be installed and are configurable across any of those for this purpose, for the purpose of customer identity and access management data, the data store that in order to have all of the capabilities we talked about is actually delivered as software that's configurable and installable in your own cloud environment or on premises in your data center, in order to meet many of the requirements and compliance requirements.
It is not just given as, as the cloud service, in which case it's fuzzy, where that, where that information is, we do have that available as well. But from a client's perspective, we highly recommend you use our software based solution for the directory itself to meet data, residency requirements and so forth.
In terms of the components, there are five key capabilities that our platform provides single sign on, which is Federation server.
Again, can be delivered in the cloud or on, on premises as software. We have multifactor authentication, which I talked about, which has both a mobile aspect in terms of the client, but it's actually delivered as a cloud that is actually delivered as a cloud service. And it works best as a cloud service interacting with your applications natively.
And then the third component in, in the access management realm is, is an access security solution, which allows you to put policy in front of your applications, whether they're in the cloud or on premises, which is access controls, which by the way, is a key aspect to GDPR is, you know, governing access to the actual applications, not just the data. And then we have two identity specific capabilities.
One is a data store called ping directory, which allows you, which is that flexible data store that's highly secure, highly scalable.
And then there's the ping data governance, which sits on top of that, which governs access via policy to that data you store there. And of course provided in there is the synchronization capability as well.
So, so really very quickly the, the question was asked, you know, how, how do you expire data and how you delete it? So the challenge is significant. If your data is everywhere, if as you collect customer data, you at the point of consent, what we've found is very innovative that if you, when you're gathering consent, consent itself, each consent record has its own life cycle. And it points the data which, which the customer is gaining consent to it references the reason, and it collects attributes. The consent record itself has the attributes of timeframes as well.
And so that's your audit record of gaining consent? What the data is that was collected by attribute, maintaining an expiration date, effectively the applicability date of that data. And then that consent record writes policy by individual consent record by the individual, a policy, which, which sits in that data governance layer over the data. And so that basically allows you then to manage much more effectively the entire life cycle of the consent and the data and expiration. And so we see that as actually unique.
So the da, so in other words, the expiration data isn't stored necessarily with the data it's stored with the consent record, because the consent record is effectively what is has to be auditable. And also what's gonna, what's gonna create the policy across the data store company access to that data.
So,
Okay. Thank, thank you.
Thank you, Matt. That was very interesting. Now I've got another interesting question. That's come from the participants. And this basically says how much, if at all, would the guidance framework change if customer equals employee?
Now, that's a really interesting question because in, in the case of the, the employee, you, you, you have different different forms of reason for processing. So for example, in, in, in the UK, if I'm an employer, I have to keep certain information about my employees for taxation reasons.
So there, there is information that an employer has to collect, which is required by law, and it is not subject to the consent process. So E equally, for example, the right to work and the right to residents are things that an employer may have to collect and manage equally. There are some things that the, that, that the employee may consent to.
So you have a combination of two things, but in principle, the framework applies. You have to know what information you've collected.
And it's often the case that individuals within an organization will take it upon themselves to keep their own spreadsheets of their team or whatever. And that's personally identifiable information that needs to be controlled. There will be HR databases and, and other things. So all of those, the GDPR applies to all of these.
And in, in terms of employees, some of the information that you collect may well be sensitive information under the definition that I put later on, for example, trade union membership may required because you are collecting union Jews through, through a payroll or something like this. There may be also a note of physical disabilities or illnesses that employees have. So all of that kind of information is subject to the treatment with sensitive data.
Now, having said all of that, so basically everything applies and it's just as bad to lose data on your employees is just to lose on your customers. So over to you, Matt, how would your solution manage if in fact, we substituted employees for customers?
So, so yeah, so we actually have solutions for customer identity, access management, employee, and partner identity and access management. So really in all three, the structure of the data is typically quite different.
So, and, and especially from an identity and access management perspective, employee data, as you start thinking about it is typically housed in fewer number of systems that are already have a lot of controls in place. So for instance, an HR system. So then it becomes an interesting question about in, in the, in the world of employee data from an identity access management perspective is called provisioning.
So, so where is the, the data originate? And then how is it provisioned or shared with all of those systems that need that information?
And so, so the good news is from a ping perspective, the way in which we handle that data is typically closer to compliance outta the box than consumer data, cuz consumer data ends up getting shared more to different marketing systems and different systems of all sorts CRM systems and, and so forth. Whereas employee data is already, typically, again, most organizations, I can't say this for all.
Again, housed in very specific HR systems, it's housed in active directory, it's housed in those instances. And we, we provide controls of course, to, for access to those systems and, and how we use that data from an authentic and access management perspective.
So it is, is generally applicable similar in some ways, but a lot of what I talked about by definition because of the, the, the nature of where that employee data is stored, isn't as applicable, let's just say,
Okay. Okay.
Well, thank you very much, indeed. Well, I see that we've now exceeded our hour. So I'm going to have to bring this, this webinar to a close. So what I would like to do is to thank Matt from pink, very much for his Aite presentation and his description of how pink can help with this important problem going forward. The recording for this will be published afterwards, and we will have a record of the questions that have been asked that haven't been answered and we will endeavor to try and provide some kind of an answer if we can.
So with that, I'm going to say, thank you very much to Matt and thank you very much to the participants for joining and for asking questions. Good afternoon. Thank you. Thanks everybody. Thanks.
