Transcript
processed by BigADdy and how BigADdy brings different options onto the table to help you better process these data subject access requests. To begin with, first, let's understand what exactly is a data subject access request. So when a user gets onto your portal to process a request for a specific data subject access request, it could be submitted via your website through an email or through a phone call. Once the request is submitted, the administrative side of elements or the organization is then required to appoint a data protection officer to in turn look at different data sets or across different data sources to look for information related to the specific data subject in the question. This is where elements like BigADdy come into place and BigADdy is the only vendor that can actually perform this in such structured databases, data lakes, and even on prem data sources and also in the cloud. While most of the other tools only look at different account data, we are also able to look at the data related to a specific user and not just where the specific identifiers are. So how is BigADdy different related to any other product in this space? BigADdy uses something called S-correlation. This is a very simple and unique identity correlation approach that leverages the identifiability of personal information in order to find personal data and correlate it to the data subject. This allows BigADdy to deliver capabilities imperative for the compliance with respect to the respective regulation. In simple words, BigADdy uniquely ties all the PI to specific individuals in which is the only best way to properly handle a specific data subject access request. And finally, we also demonstrate high-value results when validating a deletion request by applying various safety nets and approval cycles before that data is actually processed to offer further deletion. Given that the correlation is now bringing so much information related to a specific data subject, that leverages or puts us in a position where we are able to process all the data subject requests properly, efficiently, and effectively. So once at this stage, BigADdy is then able to perform different set of requests and this could be a view request, a correction request, or even a delete request, consent preferences, or request for do not sell or share the information. Once a request has been properly handled and processed, we will then be able to record all that information and process that request until it's been completed or concluded or resolved. Now when we look at the DSAR itself, there are two sets of operations that are happening here. Operation one, which happens on the consumer side, where the consumer is able to process the request or raise the request using different options. And operation two, which is happening more on the admin side, where somebody like a data protection officer is able to process that request by effectively using tools like BigADdy, which allows us to go ahead and process and complete that specific request. Now let's take a look at how this is actually being processed on the BigADdy side from the tool perspective. So here is a quick example of how it looks like from the consumer side. Imagine this is an example website where we can ingest the information from the privacy rights within the cookie banner. That's option number one. Or we can also ingest it within options like the Privacy Center, as we have done in this example. So you go into the Privacy Center and you have a different set of options that are presented back to your consumer or end user. Based on the residency of the data and the kind of profile that we used, for example, here I'll select customer, you'll be able to perform or project different set of information back to the end user based on the profile they choose. And here we have different options that are projected to the end user, like viewing the data, making an appeal, editing the data, deleting the data, managing their preferences, or even raising a request like do not sell or share. Let's pick one example of viewing the data. And what we have done then is just ask for some basic information about the user, like first name, last name, mobile number and email. Again, this is a very basic example and it's just an example. So based on your portal, the layout of the website or the portal and the IRP, the color palette, this will be completely a customizable operation where the Big Idea team will be handholding or processing through the handholding process where we can align with your requirements in terms of how this portal should be looking like. And all this action is happening from the consumer end. So once the consumer submits this request, then each request is presented within the Big Idea portal. So all the requests will fall into the request category here within the requester. However, the first step would be to go ahead and design our site. So this is how the layout would look like. So you can design and define what elements needs to be processed in regards to the request that's being processed. What are the action items that you can provide to your consumers and users? Define more information in terms of what is that you would like to request when the user is processing that request. And of course, we'll be handholding to design the complete desktop view and also the mobile view in terms of how it should be laid out within your portal. And once the request has been processed or received from the consumer, it'll fall into the request tab and this is how it will look like. So you'll be able to see all the requests that align here based on the type of the request. And for each requester, you will be seeing the requester ID and the request ID, which is a unique ID associated with each one of these DSAR requests. You'll also be able to see the type of request. Here it's a preference or a view or a delete or an update request. Likewise, you'll be able to see the stage through which we are processing it, the profile of the consumer. So the consumer company uses ex-employee or it's a current employee and the regulation from where it falls under. For example, this one is GDPR. We can see the regulatory period, which is 30 days for this GDPR request. And we've already processed through five days and the due date is left for another 25 days here. You can also scroll to your right where you can see if you can assign a specific owner or a collaborator. And if you're processing it through a different brand or a site, you'll be able to track that information here as well. So let's take a quick look of how it looks like from the processing itself. So for example, here we can see the view request and the view request is set to go through a workflow of five different stages here. Stage one, where we are confirming it's the respective employee and we confirm back with a designated template. So example, once I process the request, it will say, okay, we have received your request and we'll process it within X number of days or X number of hours. Stage two is where we are authenticating or validating it's the exact user who they say they are. Example, we can send them a message or an OTP with an SMS text or message, or we can send them an email with a validation link so that they can validate the user account here. Step three is going to be collect, where we are able to process that request across different systems where we want to scan for the information and find all the information about that respective user. Step four is going to be review, where we see all the information that has been acquired and we can then pick and choose what information should be included in the report. For example, here you can include or exclude the report, or you can also choose a different set of fields where you can also mask the information before that conclusion report has been sent back to the user. Step five is where we're going to complete it and process that request. During this whole workflow, if there is ever a conversation between us and the data subject, you'll be able to track that information within the communications tab like this. And every action that has been performed on this specific DSAR, you'll be able to try and track it. You can also see the action that has been performed in the review stage at this, which stage it has been performed. What is the status at that point and who's the user who's performed this action? And should a user supply or request or raise multiple requests for the DSARs, you can also see them grouped under all the requests coming back from a single user. And once the request has been processed, you'll be able to see the completed report as well. So when we process that request, you will see the end user report look like this. And when you click on the report, you'll be able to quickly do a preview here. For example, this is the review report of Matt Oliver. And when we process that, you'll be able to choose what information to be included on this template. And again, please note this is a default template report. You can design, define multiple templates based on the profile or based on different options that you have. You can choose what information must be included in this report. For example, here we have lots of PI information that's been included in this report. If you want to, you can mask any of this information and you can also choose whether to include or exclude any of this information within the report. And that's how the report final report would look like from an end user perspective. Likewise, when you process a delete request, instead of only four or five stages, you'll be seeing more stages. So you'll be seeing an update request here or the stage where you can confirm, verify, collect, review, update, approve, and then complete that request. And all this workflow mechanism is being defined by the users. So you can actually see or define what workflow should be updated for each one of these requests. For example, here, when we look at the stages, now you can see there are almost seven stages. So you confirm that you have received the request. You verify the user by sending them an SMS or text or OTP or a validation email. We collect all the information where we have the scanned results grouped together for the specific data subject access request. We review all that information, we process the approval stage, and then finally we update it where the deletion is really happening. And then we process the complete request. So there are different stages through which each DISA goes. And as you can see here, you have a complete opportunity to customize how your templated response would look like. And if you close the request, how would that automatic response look like? And also, if we needed to trigger certain APIs, we'll be able to call it at this stage. So there are different set of options at each stage of this workflow to define and call any specific functions that are pertaining to a specific DISA. Likewise, there are different set of options that are available in terms of setting up the regulations, giving an automatic integrations, profiles, permissions, etc. So there's a lot more than what meets the eye at this stage with respect to the DISA itself. And of course, we also back it up with a specifically defined, designed dashboard, which gives you an insight in terms of how many open requests are there, what is the current status of each one of those, what is the response time looking for each one of these in terms of the request that has been received. You can also filter based on specific regulations or timelines like this. We can also look at a breakdown in terms of the profile types. We can look at the open request trends, closed request trends, and also a quick insight into where we are receiving this DISA from. A nice geographical map, which kind of gives you all those insights in terms of what exactly is happening from a request perspective. So in simple words, we receive the request from the portal or through an email or through a text message. The request will fall into the request tab here, which kind of gives you a quick alignment in terms of how you can process that request. For every request that comes in, you can see an associated regulation and the associated number of days to process that request. And it goes through a workflow where the AI kicks in and we can also automate the complete process from receiving the request to resolving the request. And it goes through different stages. And once that is processed, you're then able to conclude that by looking at a personal report, which includes all the information. And of course, with the option of masking it or hiding certain pieces of information or including or excluding this piece of information. And finally, we conclude that report by closing it down once a request has been processed. Now, that's a very simple mechanism in terms of understanding how the data subject access request works from the BigID perspective. And I hope this has given you a basic insight into how it works. Of course, there's a lot more than what we are seeing right now. We only managed to scratch the surface. It'll be a great pleasure to us to schedule another session where we can go much more deep dive into this and understand all the configuration elements of this and also how effectively we bring other options onto the table. And I hope it's given you decent insights. With that, I wish you a wonderful day and a good time. Bye-bye.
