 Moving on, in this part, we'll figure out how all the assets which we had created for the DAS is being reused for the SaaS business of ZOTAP. So one of the foundational difference of the SaaS business is ZOTAP started managing first-party data assets in the sense this is going to be a managed service provided by ZOTAP, where the first-party data is brought into the cloud platform of ZOTAP. Whereas in third-party, so whereas in the DAS business, it was exclusively the third-party data. So a couple of changes when you talk about SaaS is the first thing which comes into mind is the tenancy. How the tenancy and what are the additional attributes which needs to be managed. And this is like what I have this third here is the various angles on which you need to think through when you are moving to a SaaS platform. So one is the organizational language for once you say SaaS, you need to have some sort of organization concept or a company concept in the sense you each of the organization which is coming into the platform has its own space sort of. So as a SaaS platform, which is a data driven application, you could bring in say a telco organization, retail organization, CPG organization, whatever. So even a finance organization. So that context goes in. Second is with the organization, there is a vertical. So vertical is a little higher level in terms of what are the categories of the organization which you are going to serve into. And with that vertical, the additional complexity that comes in is the regulation. Say for example, a regulation for a pin type might be different from a telco. So that is some context which we need to be aware of when we are working for all the privacy semantics. This is again, we need to again cross-position everything with the data protection bill. If it's a people-centric data, there are commonalities across all these. But since the data protection bill is also talking about the non-personal data, so this is also going to throw in additional complex space. Then moving in the data domain itself changes. It's more declarative. The quality measurement or the data profiling of certain retail data or e-commerce data is going to be fundamentally different from my insurance technology data. And the security is again based on the top two dimensions, the organization, the vertical, there are going to be changes. The lifecycle can be again dictated by the customers. One customer will say, probably you can retain your data for 365 days. Another customer will come and say, no, just 90 days of retention. And that also has an implication of the kind of data which he brings in. So he can have various kinds of data. Say even the customer data, he could bring a customer profile data and identity data. An identity, he could have a shorter TTL of 30 days. And for the profile data, he could have a longer TTL of 360 days. So that is why the lifecycle changes. Processing is pretty obvious. Storage, any SaaS, the storage that changes in terms of how you arrange and manage the data. And the final thing is the metadata which has a semblance to the catalog which we talked about in the previous sessions is also going to have a change here. And the other items which is going to change is, say when we were in task business, primarily our application was towards the ad tech in terms of the data outflow or whatever insights you derive from the data was mainly towards ad tech ecosystem. But once we moved into science, what happened is we have to also solve for analytics use case for our customer. We had to come up with additional derivation use case. So the MLA based derivation became much more complex. Then instead of just the ad tech as a domain, we also had to serve for the marketing domain. And ad tech is a subset of your marketing asks in terms of how many operators marketing domain. Then personalization is again a subset of marketing. But the reason I have explicitly mentioned personalization is personalization is generally more like a real time use case. So whereas bulk of the ad tech and the analytics use case could be driven by batch mode of computation. So there is a computational difference. So these applications or the usage of the data brings in additional context into how you are building your certain things. Say the consent filter, which was done as a batch system. Probably it was a library before, but now you may need to build on a lookup based system, which can serve a personalization use case in real time. And the other implication is the additional application usage context has a direct implication of how you have consented collected consent and the preference from the customer that was that we saw in the past in the past sessions. So these are the additional things from the application or usage context. Then the last thing is anyone building a SaaS platform will be aware of. I'm just putting in terms of how you architect the platform. Say if you're going with a shared everything or a shared nothing, architecture has a big say in terms of how you're going to manage your data assets. And in ZOTAP, at least it's a hybrid mode. So that's why I put the shared more stateless control plane. You have the control plane where the data and flight just come through for some processing and the actual storage and all the layers is in a more of a shared nothing style of architecture. So that is more like a hybrid mode of architecture, which is being followed. What this entails is the catalog we talked about in a couple of slides before is going to be on steroids. So this is a very, very, very foundational stage. And as I mentioned, there are many specialist companies which are coming here to solve these problems. So what I have shown here is a graphic representation of what all potentially could go into the catalog. This is also based on the evolution which I showed in terms of data catalog. It need not be a single data model that depends on how your domain functions. Say if you are going with a data mesh kind of architecture, the modeling here might be a little different in terms of how you make these kind of connections between each of the entities. So if you think about it, my question is which user, from which location, from which org has access to a data set in a particular, from a particular source. So you could, it's like a combinatorial problem here. So you are looking at all these core entities. So what I'm mentioning here is the ad tech is a usage context, the user is actual user. So he carries access context. Then there is a governance context in the sense what is the rule and who has set it. There is a ownership context. Then if you come on the left hand side, there is a schema context. So this whole thing comes into play in your catalog. So this is more like a reference model in terms of how the complexity of the catalog evolves. So this is something data intensive SaaS company. Say you are creating data platform of thoughts for any of your end customers, how that morphs. This is just a representation of that. And this is happening in our company as well as we see. Other changes say from a SaaS reusability perspective, one of the thing is if you are behind the scenes SaaS platform, possibly you may need to have some integration with content management platform. The CMP there is a content, sorry, it's a constant management platform. So there are many platforms and a couple of them are very mature in Europe. You have one trust, which is one of the leader. Then you have user centrics, Didome and bulk of these platforms, many of these platforms. So they help in collecting consents and digitizing it. And this is mainly from the digital assets of the customer. So the website, app and all these things, you could go create your own preferences, create your own grammar, you can create your consent. Second thing is once a consent is being collected by the CMPs, you also need to have integration capabilities, both from a server to server perspective is what I have told S2S. Because if you remember consent collection is one pillar, then you need to master it or manage it. Then you need to also orchestrate it for all your downstream systems. So you have three things to do with the consent. CMP will primarily solve the collection path. The S2S path is the feeder systems for downstream to get in concern from various legacy systems as well and get it into a common platform. Then we also have a SDK mode where say, if you use the SDK on your websites and apps, you could actually use the data layer behind the scenes in the front end and actually push the content directly to your app for it to do the downstream activities of mastering and orchestration. Then the orchestration of the consent, because you have created a unified consent view, that has to be fanned out. So primarily orchestration is nothing, but you are kind of taking the data and making it available in a more like there are two manners, more like orchestrated manner on a choreographic manner in terms of all other pipelines. And these pipelines need not be exclusive to your platform. Downstream customer systems, which are not readily integratable with the platform also needs this consent information. So this becomes like a fan out kind of use case, the consent knowledge being fanned over the various customer systems. Then the consent master object, which is constructed starts having the purpose and the IDs apply to it. So in the past, when we were running DAS, primarily it was a yes-no kind of parameter where we could use data partner-based consent and say data partner yes-no and remove it only based on the IDs. And if it's a global consent, just remove it. But here, since we are talking about this application or the usage context, the purpose and the IDs of each of the purpose becomes a core entity of the mastered object as well. So the consent object itself becomes much more expanded than how it would operate in the data as a service platform. Then comes the changes for the infra security and validations. One thing is, it depends on how you architect SAS, but the typical, I would say safer way is to start looking at network perimeter security as well because you want to have minimal blast radius because you're starting to engage with real first party data of the customers. So that is a concept in security called minimizing the blast radius in terms of say some intruder has access to specific areas in your network. By segregation of the parameters, he's not able to get into the other network where the other sensitive data is available. The access control itself became a little more attribute based access control. If you remember, we were talking about in the catalog on steroids, we just touched upon this aspect as well. So the location becomes attribute from which location he's coming, how much time he needs to have access control. So these all becomes attribute of the access control itself in terms of how he's going to access the data. You need to invest in key management mechanics, secure key management mechanics, because you are going to integrate with many of the customer systems, in which case you could have many AA keys which are authenticating themselves and operating themselves for various integrations. So the key management becomes a little more critical than if you're operating a singular task platform. Then one of the major changes is whenever you go with first party data collection, you are bound to get PII or personally identifiable information in the raw format. So again, we applied the minimum blast radius principle here where raw PII has no human access within the platform or within our interface UI interface. The only places where raw PII is accessed is via programmatic access, via deployed applications within the system. And of course, there is a layered separation of where the application is having microservice, that network and how the core data network is going to exchange with each other. So there are multiple provisions there, but raw PII management becomes essential and critical as well when you're doing a SAS. Then if you remember in the DAS, we were accepting hashed email and phone number in say MD5, SHA1 and all these formats, but here we had to become much more stricter. We have to be adherent to the latest and greatest recommendations from the security community, cybersecurity community. So SHA-256 is the minimum requirement. So I put as only SHA-26. Of course, we are happy to get a SHA-512 LMS, but the minimal is SHA-256 in terms of any hashing requirements which comes into the platform. So you have to, I would say, invest your technology bits to achieve all this as well. Though these come under infra and security, if you think about auto scaling or a system which has to be more self-serve, you need to actually have programmatic or technology investments to achieve all of these things. This is more like the certifications which has helped us and helped us get a good standing with the customers saying, okay, the data is safe and we have a certain good level of standards. If you notice, there are some certifications like HIPAA because we don't do healthcare data in our company. So given the scope of what we operate on, the ISO 27000 series, I've just listed all the sub items in there. BSA, CSA, BSI, CSA-START, that is a British Institute, a CSA-START. Then SOC2, of course SOC2 is something seen as a, it's essential going forward for anyone who's running an independent audit on their process and data assets and controls. E-ProVC-CLIS is something which comes from you. That is mainly, it enhances your posturing towards GDPR compliance as well. There are a couple of other certifications which I have missed out because it was very domain specific for us, but you have to take your vertical context as well as the data protection bill context and look at these certifications which are applicable for the company. Currently, we are investing on a couple of advanced technologies over the last two years. The PECT as it's friendly called Provisy Enhancing Techniques or Technologies have seen a good growth and there was a efficiency issue in the past in terms of how these enhancing technologies work because they were prohibitively costly in some cases and many were under research, but now they are getting commercialized. So ZOTAP is also investing on them on the PET techniques and the second thing is we are looking at more AML-driven semantics for the data profiling as well. Say suppose a very simple use case, suppose there is a schema and the schema is not getting adhered to and not adhered to is a very simple scenario, but say the schema was not supposed to push in a PIA in that particular data bucket, but inadvertently some customer system had pushed the PIA, how do we prevent it or how do we raise alert and immediately delete the data and raise alert to the customer that this is happening and I'm going to block this data from coming into my system. So these are a couple of things which I would say are more like a value add service from an end customer perspective, but if you think from audit and compliance perspective, it can remove lots of headache in terms of how you manage your data. And the third thing is there has been a framework called linden.org out of EU. By far we have found that is, so if you look at cybersecurity, there is a security threat modeling framework, same for physical security as well. You know what is the security threats and you can model the threats and you can look at the various activities. From there you have a bunch of activities in terms of is that threat applicable to you? How do you mitigate the threat? So like that linden has provided a privacy threat framework. So a simple example is how reidentifiable a data asset is, even though a data asset may not have direct identifiers, you have a quasi identifiers in it. When you combine three data assets with quasi identifiers, probably linking it to a real world person becomes, the probability to becomes almost close to 100. So these are kind of a privacy threat framework which linden has created and that can serve as a, that serves as a nice model to look at our data assets and figure out what is a privacy threat. And once you figure out the threat, it is same like security. So you have security, you have the security mitigation controls and automatic mitigation, yay mitigation, whatever. So we also looking at, okay, once we have a privacy threat, can we automatically mitigate it so that our customer feels that, okay, if the data pipeline is handled by this particular company, I can be rest assured the privacy threats will be mitigated for all the downstream use cases. So consent is one aspect of it in terms of the orchestration mechanism we are achieving it, but privacy is the other aspect, which enhances the standing to say the data protection officer or data impact assessment report and all these things. Then second thing is, if largely bunch of these data technologies has, as I mentioned in one of the introduction slides, you have the producer, it could be the product data engineering guys or the end customer which is being collected, the data. Second thing is the business user. Now with all these regulations, you have this key entity called the data protection officer which is coming in between. And he has a very huge responsibility on his shoulder in terms of mitigating all these risks. And in current world, he really doesn't have a clear tool. The tooling is not mature. So that is another development area which we are looking at in terms of what we could give for the data protection officer himself to do stuff. Then NISD is another privacy framework. It is not a threat modeling framework. It is a framework. It talks a lot about privacy by design and privacy by default and general recommendations to achieve it. And I would say we found it to be a really enriching framework to work with our own development efforts at this point in time. Then moving on, this is the last part in terms of where this is more from a ZOTAP lens. Suppose say ZOTAP has to comply to the PDP. I have again mentioned as PDP, the data protection bill. Of course, data protection bill hasn't been in the final format yet. It is still under bit of scrutiny and couple of things are going on. But with the current format, whatever it is, we were just checking how easy for us it is for us to comply. Data sovereignty and all these are already taken care of because as I mentioned, we don't actually do any cross border data transfer. None of our use case demands it. So, those are all a couple of, just an example of how our lens is bit different from any of the companies. Largely, this is a deja vu of what is a slide we had put in GDPR. So, it's a government of India bill. Again, it's going to have the org effect and it talks about all the aspects which is there in GDPR. Only thing is there is some language change of a data controller. You have a data fiduciary and couple of other things I haven't mentioned is there are some dedicated authorities as well. You have someone like a Consent Manager, you have an independent auditor, you have Appalachia authority. So, you have a couple of designated roles or defined roles, additional roles. So, GDPR as far as I remember did not exactly define a people persona-based role, whereas data production bill is doing that as well. So, this slide was just to represent the GDPR bill and data production bill from a ZOTAP lens how it looks like. So, more or less I would say 90% looks same in terms of where we have effect. Now, coming to where there might be additional investment. One is, I have just called out in the latest version, the 2021 version, they have taken the NPD Non-Personal Data Protection Bill and merged it with the Data Protection Bill, which was mainly the personal data protection in the past. So, that is a new area and we are watching in terms of what are the changes that is bringing into the system. Coming to the previous personal data alone, if you take off the scope of non-personal data, if you look at why they are personal data, one thing which changes the sensitive data management, the catalog is a bit different. I would say there are some special additional categories of sensitive data which data protection bill is defining and we have to adjust to that. Second is, there is a concern manager entity. So, we are looking at what are the artifacts he might need if he has to come and check the data fiduciary. So, there is an additional role. So, you have a concern management, largely concern management more or less the language is same, but what are the artifacts which might be needed for the concern manager that might be different and preferences there are some difference as well. PA management largely looks the same, user information, the right to forgotten has some level of additional elaboration in terms of right to restrict disclosure. So, that is one area we are looking at in terms of how exactly it changes and what is needed for that. Access management more or less looks changed. Auditing, as I mentioned, the primary changes you have an entity called the independent auditor, not entity or persona called independent auditor. So, we are looking at what are the changes required for that. The minimum cohort size, TTL, these are all internal implementations of achieving. So, largely not much of a change there. Ashing an encryption, again not much of a change and one time requirement anyway all the company has to go through in terms of the data cleanup to achieve compliance with their existing data assets. So, this is largely in terms of how the changes of data production bill if we could look at from a personal data perspective against GDPR, that is what we had listed here. Again, this is a slide which I have released from the initial part to showcase where all changes are happening. Thank you. That is largely what I wanted to cover in terms of this privacy mode fellowship program. Thanks Hasgeek for instituting this brilliant program and I believe this is going to really help the community and it is going to give a perspective for the overall community which is working on any data intensive business to look at what are the impacts and be prepared earlier to have to face the bill right whenever it comes. Of course, they are going to give some 24 months implication period but largely what Hasgeek community is trying to bring out as a knowledge as a prerequisite and stuff like that is going to be really helpful and thank you for having me as part of the fellowship program and hopefully I was able to give some guidance or some input into how companies can look at this particular data production bill. Thank you.