Elevate your RISE with SAP implementations: Secure PII to drive client trust and revenue

Hello, everyone, and welcome to today's webinar. Thank you very much for sharing your time with us to learn more about, data scrambling, and we will be sharing with you some of the things that Epis Labs has to offer to you as a partner. And I'd just like to introduce myself. I'm Mariel from the global marketing team here at Epis Labs, and we are really delighted to have you today. And just a few reminders before we dive into our topic. This session will be recorded, and it will be shared through a follow-up email. And if you have any questions, please feel free to send them through the control panel. You'll be able to see on the top right of your screen, there's a chat box icon with a question mark. So just go ahead and send them there, and we'll be addressing all of the questions at the end as we have enough time. And that's it for me. I'm happy now to introduce James Watson, our speaker for today. Over to you, James. Thank you, Marielle. Yes. Good day, everybody. I'm James Watson. I'm the director of global services for our privacy and security solutions, at EPUSE Labs. But I also act as one of the product managers dealing with our, product road map and, new features that are coming through. I'm very interested to talk with you today because we find that this is a space where we talk around security that, is often quite difficult for, partners and for ourselves to try and fill the complete picture. And therefore, by working together, we think that we can provide the right solutions to the end client, but there's opportunity for both parties there to be able to, identify the opportunity, for development. So, I've worked within EPIs Labs now for around about nine years. And, during twenty seventeen where we were getting close to GDPR, I was working in the European team for, the service delivery at our organization. And with the advent of GDPR, we had a request for, a volunteer to be able to move into the privacy space, and I volunteered to do that. But since that twenty seventeen time, the privacy laws have expanded globally through, many, many countries now. And they all have some similarities, although they are unique to the country and there are some very specific, nuances that need to be addressed in the different countries. There are some common tenants that we find are true in all cases. And especially when you're going through something like a data migration to RISE, where you're starting to deal with complete data copies, migrations, maybe selective data transfers, and you've got large team members from multinational organizations all trying to handle the same data, it starts to create some serious concerns around, data privacy. And when we sort of think about those common tenants, the things that are true across the board on all of these different privacy laws. We have a combination to be able to think of things like, the right to access in a production system and the right for removal where data would be deleted, the proactive need to be able to automate retention and proactively identify data that should be removed. And then in the test systems, we have two driving elements here. Now the first one is the privacy law where it talks about informed and explicit consent for the use of the data. And what that sort of boils down to mean is, if you have an employee, then you can very quickly justify for your employee why you need their banking information in production, why you need their address, why you need their you need to be able to payroll them. You need to be able to, provide taxation laws. You need to be able to, confirm that everything is done for that employee. However, most clients don't have informed explicit consent to use that same data for testing or in the case of what we're talking about today, a RISE migration project, where that data is gonna get transferred between appliances and get used through project. So where you don't have that informed explicit consent, you then need to be able to address the, personally identifiable information, but you still need a workable project. And that's where software like ours, comes into play. The second part when we're dealing with nonproduction is actually SAP's, data processing agreement that they enter into through the RISE contracts and, and in fact, traditional SAP contracts, where they specifically state in their data processing agreement that production data should not be used outside of production. This is a legal liability thing for SAP that if you choose to do so, then the liability doesn't sit with them. But even the software providers are, promoting this message now. So as a partner that's trying to, engender trust and build through the s four project, you do want to make sure that you're up to date on these items and that you have a sensible answer to be able to go back for them. And that's what we're gonna talk about today very briefly. Excuse me. So to start off with, I just wanna talk about a very common scenario on what that means for businesses. So we're just gonna talk about the idea that in your SAP instance, you have an employee. That employee goes and does some, project work and incurs some travel expenses. Therefore, in SAP terms, that employee now needs to be created as a vendor. And that vendor, will have financial transactions associated, payments, and FIDOCs, within the clusters. If we are dealing with s four, then it's also a business partner that's been created. So that same personal data is now an employee, a vendor, and a business partner. Now in certain industries, it's even possible for that employee to also be a customer, that they are purchasing something in a b to c industry. And because of that proliferation of data, it means that there is a huge, complex data model within the SAP environment where the same data can get referenced and proliferated through multiple tables, and that's just the standard, content. So with Appius Labs software, we've spent the last, few decades working with SAP to be able to define our own business object definitions, which identify between multiple SAP instances, the definition of an object, the specific tables within that object. And then for the data privacy side, we've gone down to the field level to be able to say, in this example, everywhere that a name exists between the zero customer record in BW, the business partner in CRM, or the customer object in ECC, We've mapped out that integration so that we know if we need to process that individual, we can process them, consistently between all of the systems and provide a new scrambled database or in the case of production, the data removal. But as I mentioned, this is just the standard database. Now data sync manager, the product set that we're working with here, is a an SAP certified, third party add on. It is certified for works with RISE with SAP, so it can exist within the RISE environment, and it is installed directly and is then fully extensible. So as well as the standard content, we've then moved on to build a discovery program that utilizes that predefined knowledge to be able to identify the data elements and domains for the personally identifiable information. It does a wildcard search of your dictionary and identifies both the standard and the custom fields that are integrated that appear to hold personally identifiable information. Once we've run the analysis on this discovery program, we would then step into a workshop process to be able to output a data privacy workshop and system analysis document. Now this document contains a joint view of the business requirement of how data should be affected, but then also the technical requirement of exactly which table fields are related to those different data types. So this is a standalone engagement that we can work with, with your clients. There's no license involved, and, it's a small five day engagement where, typically, we would have, two to three days of system analysis, a day of running workshops, and a day of actually preparing the output report and providing everything, through. So that'd be sort of per system. There is some concurrencies in terms of the system analysis if there's multiple systems in scope, but we can provide this as a small discrete service to be able to move through. And in terms of our partners when we were executing this, if you're already engaged and you understand the business, the processing, then, actually, you will be able to have consulting services to advise on those functional requirements. We are data experts. We're just doing the identification of the personal data and then identifying how we can pass that through, for processing by then investigating the integrations between systems, the functional business requirements, what are the challenges for API integrations if we were to affect emails in a certain way, etcetera. So there's a much deeper business engagement that occurs as part of this analysis program, that we look to our partners to provide, and we provide the specific data analysis. Additionally, depending on your structures, we very specifically do not provide legal counsel, and we have no interest in doing so. So if you have that ability internally that you will provide, data privacy legal counsel to, to end clients. We again can provide the technology that will support the solutions to those issues, but we would work with you in the engagement to provide what the client needs. So that's our first stage with discovery, system analysis, and, then workshops and an output document that is freely shared to the client with the full PII mapping and essentially the business case of what needs to be done to manage compliance. So then we move on to the appliances for actually processing data. Now the first, the we're going to talk about each of these individually. But if we think about production first and starting at the top left, data disclose is a direct response to the right to access. So sometimes referred to as a or a subject access request. The right to access, requires the ability to quickly and efficiently provide a summary of the information that you hold on any data subject in your environment. Data redact is then a response to the right to removal. And very specifically, our redaction process deals with selective data removal from a record whilst maintaining the referential integrity of the SAP instance. So what I mean by that is that we would never fully delete an employee, their vendor record. We would selectively remove the name, the bank details, the telephone number, the address, email address, etcetera, the personal data from those records. The benefit of that being the regarding the vendor items where you have financial transactions, you don't need to delete that business data. You can keep your financial history because the vendor record still exists. It's just been de identified through a redaction process. And things like on the employee records, you're able to, that keep things like gender, racial diversity. So your reporting can still exist to be able to know that you did have so many men, so many women, different races, different, sexual orientary orientations. That can all be maintained, but you don't know who the person was. You just know you did have a woman employed for these dates during that period. So you, again, you can keep the business data whilst de identifying the sensitive data and meeting the privacy requirements. Data retain is then the ability to look at the proactive identification. So this is, programmatic rules to be able to identify customers, vendors, business partners, employees, transactional data that requires data to be removed as a proactive item, and data retain will feed the data redact queue with batch cases so for business review and execution. So the actual processing of the removal is always data redact, but data retain is then one of the things that can feed the data redact, software. And finally, data secure. And this is gonna be the main use case for initial, the RISE projects and the integrations that you may have. So data secure is the anonymization of an entire client. Whereas where we talk about the redact and the disclose, that's dealing with individual data subjects in a production system. But in your project landscape, in your first copy for DMO migration for, move to s four as part of the pre steps to RISE, We can execute the data secure engine to be able to anonymize the core datasets and provide a, anonymized system, but it works on the same principle as the redaction. So we don't change the referential integrity. We keep everything looking the same. So the data still has as this sort of animation tries to show, it has the same shape. It has the same meaning. It has the same integrations. It's just that whereas your employee used to be called John Smith, they're now called Edward Norton. It's whoever you want to whatever fields you want to change will be changed. And importantly, because of that integration and our, business object definitions, you have the complete, consistent dataset anonymized through the landscape. So like I said, in terms of RISE, where you will have multiple project instances, multiple migrations, you'll be creating the new landscape. You can ensure that the anonymization is run before people have access to the data. If you've got legacy system migrations coming in as well, you can do selective, scrambling where you would only process the additional objects that have then been loaded as part of that migration run. It's a very flexible data transformation solution, that comes with a delivered essentials policy that covers all of the core master data that you would expect, with a plug and play option, but is then also fully extensible for if you are going to be doing a brownfield and you're taking the customizations, we can extend the software to ensure that the data anonymization is consistent across both the standard and custom solutions. And that means that when you get through to the rise completion, your nonproduction instances are already anonymized. If you then choose from your go live to do another refresh, Data Secure can continue to be used in an ongoing, use case with the defined, policy. And once that policy is defined and installed, it's something that you, as the client's SI, if that's your role, will be able to execute. It's typically the basis team that will actually execute this software. We can also provide training on how to manage, changes and improvements to the policy. So following that initial installation, implementation, and activation, of the software, it's something that, can be managed by you or by the client directly as is the most appropriate for them. Additionally, moving with, RISE, we quite often see a move to SuccessFactors and other OData Cloud applications. And the data secure engine has been designed to be able to make an OData call to the ABAP stack to be able to read the same entity data from SuccessFactors and the info type data from, from the ECP, ECC, whatever it is that you're using. And it calculates the new values and make sure that they're consistent for that user partner relationship into SuccessFactors, updating to the same values as a direct update to the database in the SAP instance, and, again, calling that OData API service provided by SAP to SuccessFactors to be able to, push that update into the EC environment. So we have the ability to do the cross system multiple SAP systems. If you have BWs, if you're using CRM, SRM, if you're embedding, CRM into your, s four RISE, then again, it's just another package to be activated that will contain the embedded CRM configuration for anonymization. And if you have OData appliances applied, you're able to move out into that. In terms of product road map, we are currently working on our first project to integrate Salesforce, with SAP as well. And we're exploring the next focus between Workday and SAP c for c to be able to integrate those additional appliances. But we're moving away from relying on, the ABAP stack and looking at new technologies that will allow us to process Salesforce only, for example. And that will mean that we no longer need that OData call to bring things into SAP prior to update. But at this moment in time, we have the OData API available and ramp up for Salesforce, and there'll be more news on that to come in the future for other appliances and enterprise level anonymization. Now in terms of those production applications, just to be able to think through the scenario, data discloses built with a pre index search function between the systems. So you can enter a, a personal data item, in this case, the last name of the person. We will do a search of our index data, and it will, apologies. I managed to hit the keyboard there. We'll do a search of, the index data and, return the keys from each system, as you can see between, in this case, ERP, CRM BW, and potentially SuccessFactors. We return those core keys and some base data for validation of, which keys should be included in the disclosure. Once that's selected, a second call is made to be able to go and find all of the personal data from all of those systems, and that's read into a summary view for the user to be able to configure. Once that is ready, we generate a password protected, encrypted PDF, which is ready to be shared directly to the data subject. So that can be done through a mail merge. It could be done on a direct email process, whatever's more appropriate. But if that data subject then responds and says, that's fine. I see the data, but I want you to remove it, and you have no legal justification for keeping it, you can then submit from data disclose into data redact for that selective data removal to be able to, go and, remove just that data without, again, impacting the referential integrity of the environment. So disclose and redact work on individual requests, whether that's a request for access or a request for removal. Data disclose allows front office direct search disclosure and, move forward. The final software item then is data retain. And data retain, as I mentioned, has a number of rules that will get built out as a retention policy. So an employee left employment more than, ten years ago, but you can have different retention policies as implied here. You've got a one year retention rule and a ten year retention rule, each finding its own list of keys. And the reason for that, if you think about it, is things like the, next of kin or family member information on the employee record. So talking about myself employed by FPU's labs, they also have my wife's personal data held as an emergency contact should they need to contact them while I'm working. If I was to leave work tomorrow, at EPUs Labs, then they still have a legal justification to hold my information in the UK for up to seven years due to the tax laws. But my wife's information, they have no right to as of tomorrow. She is an additional legal person that has their own rights under the privacy laws, and they would need to be removed. So with the redaction approach, with it being field by field instead of complete record deletion, you're able to create very specific retention rules, automate that process that once the retention policy runs, it creates a redaction request, submits that to the system for an approval process, by the client, and then the selective data removal will be completed, to be able to, actually deidentify that data. So then we get to what does the project look like. Where are those integration points? How do we work together? And there's a normal journey that most, clients need to go through. This is not specific to RISE. This can also just be a client that is already on RISE and needs to address privacy. They could be on traditional on premise, and, again, they need to address privacy. But the first thing that they need to do is an impact on risk assessment to be able to identify risks. And this is a key area where we look to our partners, as I mentioned earlier. We will do the discovery and the technical mapping of personally identifiable information. We will bring that through into documentation. We'll contain it. But the broader business impact, The privacy laws need to consider everything from paper handling in offices that do they have call center staff that are, taking calls with a notepad and jotting down people's personal details ready for post call work, and then walking out of the office with that notepad to accidentally leave it on public transport, that is a breach of, data privacy. So there's a much, much broader business impact review, and we will help do the technical bit for the SAP systems. We then have to think about who can access that data. So we know what data it is. We have some partner solutions with our partner, Soterian, That is an alternative to GRC that comes with ready made data privacy, rules along with segregation of duty and traditional, access risk. But we also have GRC resources directly that can come and work with your teams. It may be something that you offer yourselves. That's not an issue, but depending on the contract you've got in place, we can embolden the team, we can come and do the direct service, or we can provide partner solutions to be able to help, identify these risks. We then get to the actual execution. So the first step is always to clean up the backlog. So you may have been running SAP for twenty years, and we're dealing with the production privacy, and you want to re may be able to remove all of the sensitive data, potentially even market not to migrate that you don't need to bring that information into RISE, if it's going to be redacted. So that typically requires a specific project with a go live, with a cutover, with, a contingency backup restore options, etcetera. So, again, there is a large amount of project work that's going to be required that is partner enabled, and we will provide the technology to be able to do the actual physical removal, from an EPIS labs point of view. So we can work very closely together on that project. We then think about data secure, so taking out the lower systems or developing the policy for the migration systems, and having that ready for execution. The majority of that delivery would be something that FPUs Labs would do. But as I mentioned, once it's built and designed, it's something we would hand over either to yourselves or to the client as was most appropriate for your future execution. We then deal with the right to access with data disclose. Similarly, we would do the majority of the delivery, but then once it's handed over, it would need to be managed. The same for the individual right to removal and, of course, the, proactive, the retention reports. The final element is then the other area that an enduring partner relationship is gonna be needed, and that's that this is not a one off activity. Let's say you do all of this for your RISE project, but then you decide that you need to put some customization into the system. You purchase a new add on. You, purchase the vendor invoice management solution, for example. When you add those tables and start processing the vendor information through it, it does start storing the personal data in their own name space tables. So this policy and the design needs to be ongoing maintained, and it needs to be embedded into the change management process at the, at the client. And if you've got the enduring support, relationship with that client and the functional consulting, the SI activities, that's something that will fall into your remit to be able to maintain, and then you'll be able to again request technical support from us as and when you need it. So as you can see, there's a number of different areas that we can work together as partners. We also provide the partner portal, which is where I'm gonna stop talking and hand over to Marielle, where we have a partner workspace available for, for your engagement. Yep. Thank you very much, James. So as he mentioned, we do have more resources on all of the solutions, not only on the data privacy suite that is found on the client central partner workspace. So if this is the first time that you've heard of it, we're pretty happy to send over the link, especially in the follow-up email that we will be sending along with the recording of this webinar. And just to ensure that, if ever you do have any client or prospect in mind that would definitely benefit from data masking or scrambling or even the discovery call, we'll be sure to, assist you with any questions about lead logging. So, if you have any questions, please just get in touch with your account manager. And that's pretty much it for the Client Central partner workspace. And now, let's give some time for some questions from, today's attendees. And just reading through the control panel alright. Just to start it off, James, you have our first question. They're asking how flexible or customizable is DataSecure in creating different scrambling rules? Okay. So, it is essentially fully customizable. So everything from, the we've had the conversation around adding custom fields, but, also, if you wanted to apply specific filtering to be able to say that I only want to scramble vendors of a certain accounting group, or, partners of a certain relationship, we're able to create custom filters whether that is logical table selections, whether it's something that requires, app exit technology. We have exits built into the software to allow you to create conditional rules, like, say, filtering. But even down to how you actually transform the information, we do deliver a good mixture of random values. We have a good approach dealing with banking and IBANs in Europe, where it will create a fake but, real value. And what I mean by that is that it will pass all of the validations, but it will go through. But if you tell us that, actually, you need something completely unique and the for your process, we dealt with some banks recently, and they did need to anonymize the, bank account number because that was the account number. That was the most recognizable item, but they needed it to be done in a very, very specific way, and it must be value. So we were able to extend the software to be able to do that. So although we provide a number of accelerators, if you do have custom requirements that you need to be addressed, it can absolutely be done within the, within the solution. We're a bit, past the thirtieth minute mark, but I still have two questions that I think are pretty important to be addressed. So I'll just go ahead with it. Someone's asking, how is the data updated with the data secure? Does it create change docs? Okay. Okay. So no. Very specifically, Data Secure has been, designed to do a direct database update. So, obviously, the, the table logging that occurs for every change within a system, the DB tab log, that will still occur. But change documents, IDOCs, delta queues, etcetera, they don't get created. And, the reason for that is that they hold the original value. So by design, it's been very much, stated to work that way. So, the only exception to that is where we use the OData API to update the cloud solutions like SuccessFactors. There, we are doing a standard upsert through the API. And as such, the standard tracking that occurs against those API activities will occur. But, again, it doesn't actually trigger a change that then tries to reupdate ECP, for example. It is something that we're able to, configure, but it's slightly different because we don't have, of course, direct database access to a SuccessFactors instance. Thank you for clearing that out, James. And just another question, the last for today. They're asking, can you mask SAP and non SAP systems consistently? That's a yes. Obviously, we've spoken about the examples of the SuccessFactors integration through the OData API. I mentioned earlier that the Salesforce is, currently in process. We also have a partnership with a an additional provider called Datprof that if you have, sort of specific SQL databases that were created internally a few years ago that become business critical. It's a fairly common thing that happens at clients, that we have an integration tooling where DATPROF has the ability to update any database, agnostically, but doesn't have all the referential integrity domain information that we have for SAP as an ERP appliance. So we, we can provide the output file of the key and, from SAP and the new values, so not the old values because that would defeat the point of scrambling. But we can create an export file of those keys and new values that can then be ingested by a solution like Datprof Or if your SaaS provider has a solution that just needs an input list, again, we can provide that to be able to integrate. So there's a number of ways we can do it. There are API calls. There's the OData call. We have the new approach for using a cloud SaaS solution to update Salesforce, but there's also the ability to just have a file of values that can be ingested by, maybe a program that our partners design for their, for their clients where it'd be entirely something that you could own and move forward. So there's a number of ways we can work together, but as always, I am a technical guy. So it does depend on the database, the available APIs, or the available accesses if we can actually get direct to the database. We do need to, have that information to be able to advise per application, exactly what's possible. Understood. And that's all the questions we can address for today. Thank you very much, James, for your time sharing with us the data privacy suite, and thank you for our partners joining for this webinar. We really appreciate, dedicating some time to learn about data masking and scrambling. So if you need any help, we are really happy to assist you with any of your projects. And all useful links will be sent, again, in a follow-up email. And if you want to know more about Data Secure, just send us an email at the screen that you can see right below. And thank you very much, again, for being our partner. Have a wonderful day. Take care, and stay safe. Bye.