Public sector SAP data security:  Is sensitive PII hiding in your systems?

Good afternoon, everyone. My name is Josie Stretche, and on behalf of CareSoft Technology, I would like to welcome you to our webinar; Public Sector SAP Data Security: Is Sensitive PII Hiding in your Systems? To tell you a little bit about Carahsoft, we are the trusted government IT solutions provider supporting federal, state, local government, education, health care, and private sector industries. We connect our customers across The US and Canada with thousands of technology vendors, resellers, system integrators, and managed service providers to deliver a comprehensive range of solutions and services to meet organization's needs. Carahsoft, in conjunction with our vendor partners, is pleased to host and sponsor thousands of educational informational events each year, ranging from webinars like today's to accredited trainings, trade shows, roundtable discussions, technology forums, user groups, and more. Carahsoft holds a wide variety of schedules, contracts, and purchasing agreements that streamline and simplify the IT procurement process. Our contact information will be at the end of the presentation, so please do not hesitate to call or email us for any of your needs. As the master government aggregator for our vendor reseller and integrator partners, Carahsoft has assembled a comprehensive IT solutions portfolio that includes products and services across multiple technology verticals to support organizations with mission focused solutions for AI, multi cloud, human capital technology, and more. Then with that, I'd like to pass it off to today's speaker to introduce himself and kick us off. Yeah. Good day, everyone. It's a pleasure to meet you. My name is James Watson. I'm the director of global services for the privacy and security solutions provided by EPI-USE Labs. We're in partnership with Carahsoft and have a solution set designed with SAP specifically in mind. However, we have started to explore other applications as well for the challenges that we're gonna talk about today. So we're going to have a quick run through of some of those privacy security challenges, how the landscape is changing, the typical implementation process that we see with clients to be able to become compliant with the various international laws now. We're going to talk about how you can find where the data is exposed in your systems, nonproduction, and then some of the solutions that EPI-USE Labs provide to be able to help manage those data challenges. And then I'm gonna dive into a live example for you using some of our demonstration systems. Today, I've prepared an example that combines the an an on premise HR with a cloud SuccessFactors to be able to perform anonymization through the environment, to be able to demonstrate the the cross system integration and the data quality that you retain after the anonymization process is completed. And then, obviously, we're gonna try and leave some time towards the end for some q and a, where we'll we'll answer any questions that you raise throughout the meeting, and then we'll follow-up with you as Josie just mentioned within the next twenty four hours with the recording and any direct feedback that you may request. Okay. So to begin with, a little bit about EPI-USE Labs in case you're not aware of us. We are a partner of SAPs as a development partner. We have developed software for data management over the last twenty five years, and as part of the broader group, Elephant, we've been dealing with SAP HR data for over forty years now. The company has been instantiated in payroll development, and then EPI-USE Labs was spun off about twenty five years ago to be able to focus on actual data management solutions and products. So data copy from production systems, client refresh with simplified basis processes, the scrambling of data, then more recently, over the last sort of eight or nine years, moving into data privacy, the selective data removal in a production system, the data anonymization archive, etcetera. So essentially, where that domain information and understanding of the whole SAP data model is needed, that's where EPI-USE Labs comes in. As you can see here, we've got sort of 1,900 clients worldwide that are using our software. Between those 1,900, that's over 10,000 licenses sold for individual products and utilizations, and we've got a 97% client renewal rate. So but you can sort of see that that the solutions work. They're proven. They're already out in the market, And where we then have the support organization in place to be able to support your businesses in running these applications once they're in place. So I'd like to start off with just a short poll, which we're gonna ask you to answer to be able to ask how are you currently protecting the sensitive data in your nonproduction SAP systems. So are you using another third party solution or product? Are you using a custom in house solution that you've built yourself? You don't feel you currently have a need to do anonymization, so you're doing nothing, or you've identified a need, but you don't know how how what you're going to do about it, or finally, you're not sure and that it's not something that's in your in your purview. So I'll just give it thirty seconds there. If you wouldn't mind responding to the poll, it should be interesting to see where you're currently at. Okay. So let's begin by talking a little bit about the public sector security landscape and also the broader privacy landscape of what's happening around the world. To start off with, I just want to sort of tell the story of the last eight years because not many people actually have a global view on what's happening within the privacy space. So in 2018, everybody's heard of GDPR. We also had LGPD that went live in Brazil. They're both very similar. And then sort of fast forwarding through the next six years to 2024, we see a small proliferation. So there's around about eight privacy laws at a state level within The US. We we still we're all crossing our fingers for a simplified federal law that everybody knows what we need to do, but that hasn't come about as of yet despite a few bipartisan bills nearly making it to the floor. But we've seen pockets of additional laws coming through with some similar requirements built into them, essentially driving the need to remove data when you no longer have a legal justification to keep it, and the person owns their data. It doesn't matter where it's stored or processed or whatever. It's all about the person having the right to their data and being able to request data deletion. And unless you can legally justify why you need to keep it, then you'd have to deal with that compliance law to actually remove it from your system, which is always an interesting challenge within an SAP landscape. But then most interestingly, when you look at the privacy laws is when you then consider the the next two years. So between 2024 and it was around about March this year that we did the last poll of these laws, you see a huge expansion of countries that are now that are also processing updated privacy laws. So obviously, most of these countries already had something from the 1980s or the 1990s, but when we think about how technology has changed in that period, I was still a child in the nineteen nineties. I was playing VHS tapes. We didn't even have DVDs. Google didn't exist. Facebook didn't exist. And certainly, the ideas of big data, AI, Datashare, even the Internet itself was mainly contained by businesses. It certainly wasn't readily available throughout the world. So the way that the the way that we use data, the way that we share data, and the way that we buy, sell, transact with each other has massively changed, and that is what's driving these laws. But then even if we look at the oldest with GDPR and LGPD, the latest revision to GDPR was three weeks ago, and it was another AI rewrite to be able to say how are we handling how AI agents are treated within the confines of the law. So it's just getting more and more complicated for all industries and businesses to be able to do their business process whilst maintaining these compliances. Where you're dealing with international data, for most of these laws, not all of them, but for most of these laws, like I said, they're protecting the person. So GDPR is the simple example that it is the legal person as the European citizen that maintains the ownership of their data. So if they were to come out and attend a university in The US for their college time, study, and return home, Technically, they would be under GDPR rights to request the removal of any data you hold on them. How that gets enforced and between the jurisdictions, it would always be challenging, but then when you think about the largest fines that have occurred, it was actually the small country to the side of The UK, of Ireland, a $1,300,000,000 fine against Meta under GDPR terms, and that's been paid and settled and resolved. So it is possible, but, obviously, it does depend on exactly what you're doing, the nature of the breach, and the mishandling of the data. So I'm certainly not suggesting that just by having a student in place, it's going to create that level of risk for you. But it's something to bear in mind that actually as this is getting more and more complicated, as more states bring out their own laws within The US, it's gonna get increasingly difficult to be able to manage. And that's where technical solutions to manage the data are gonna become needed because you're not gonna be able to maintain that from a manual point of view. And then, of course, we have to consider the PR side of things. The these new stories are hitting us regularly. So this we pulled together just from the most recent sort of cyber attacks that have happened within The US over the last month or so, that, obviously, there's been the, Oregon drinking. There's been a few water vulnerabilities that that have been attacked, over the recent time. And we've got cyber losses at 20,900,000,000 in 2025 with public entities had seen a significant cyber risk to be able to process through. So that it's constantly in the news and it's bringing these things to the forefront of the public's mind, which again is then seeing that switch of people actually challenging and chasing these. So you have the complexity of ever changing and ever increasing number of privacy laws hitting the world, and then the increased focus through the news outlets, but then also SAP themselves. They've updated their data processing agreement, and some of you may have already seen this, already signed on to it. And SAP themselves have included the clause two point one point three. This is a screenshot after their data processing agreement. To specifically state not to apply real data from production into a nonproduction environment of both their cloud service, but also their noncloud services are also mentioned here depending on whether you're on RISE or not. So SAP are disentangling themselves entirely from the requirement to give you real test data in your testing environments, and the privacy risk that comes with that. So a lot of the laws do talk about consent, and they provide you the ability to say, if you have consent to use the data, then that overrides the the privacy requirement. But, again, as most businesses, have you got consent from every single employee, vendor, customer, contact person that you register into your environments to be able to use their data for testing? The likely answer is no. And if you did try and manage it via consent, what if 10% of your population said no? How would you remove the 10% but still have system refresh to be able to copy the other 90% who did give? And how would you manage that process to make sure only the data that should exist does exist? Consent management becomes incredibly challenging to be able to meet these requirements. So there's a lot of drivers that say your nonproduction systems can actually be a larger risk than your production environments because you can justify why you have maintained payroll information for an employee because you need to pay them. And post employment, when they leave you, you have ten year retention periods in certain states based on IRS requirements to be able to actually provide information on taxation and payments if there was an audit ever brought through. There can be other industry specific items that we've had. We've had items such as clients that have worked on government contracts where there's a two hundred and fifty year retention requirement of everybody that has worked on that contract. Or similarly, we've had universities that have payment agreements, the payment funds that they would pay out from to be able to support the students. And any recipient of that payment would then have a retention requirement according to the terms of that. And again, in one of The UK universities we worked with recently, that was a four hundred year requirement for retention, and the fund was created three hundred years ago. So there there's still another hundred years before anybody's data could be removed from that, and they're not maintaining data from students of three hundred years ago in their SAP environment. I'm sure that'll shock everybody. So there can be some real drivers that negate the privacy laws, but when SAP themselves are out in your production system, but when SAP themselves and with the focus on nonproduction systems and the fact that you are providing access to those nonproduction systems far broader than you would ever provide in a production system, it then starts to drive a need for data security, not just cybersecurity. And that's where EPI-USE Labs come in. So there's many businesses out there that provide cyber firewall protections, network interfaces, server encryptions, etcetera. But with the data that you're storing in your environment, it becomes a key risk for those businesses. And like I say, your nonproduction environments can then actually become the largest risk that you maintain because you have copied all of that data. You don't have consent to hold it. SAP have contractually said, do not do this, so you're by yourselves within the process to be able to do it. And then you're providing that data potentially to an SI who's using offshore teams, where you're now crossing international sovereignty boundaries and providing access to US data to offshore teams through Asia or South Africa or The Philippines, wherever your offshore teams might be. And the access you're granting those people would be far broader because a tester would always need to be able to submit and approve a purchasing process. You wouldn't want them to have to pass between different test teams to be able to test their process. So you're giving them broader access, giving them all the data, and then putting no controls over what's there. And that's where the data anonymization comes in. Or for anybody legal on this this webinar, specifically what the the EPI-USE Labs solutions do is pseudonymize. If that's not a term that you're familiar with, it it it is illegal just to segregation of anonymization or pseudonymization. If you were to truly anonymize the data, it would be completely random values. It's sort of the ciphered data, no linkage to any original data. There's no way to reinterpret what was there. But because of the referential integrity of an SAP system, you can't do that. You wouldn't be able to run a purchasing process without the associated purchase orgs and company codes being configured correctly for the process that you're trying to execute for the relevant materials, etcetera. So we use pseudonymization, which is to say we leave the keys. So the customer number, the business partner number, the vendor number, etcetera, all unchanged. The core enterprise relationships, we would leave unchanged. But the name, the telephone number, the bank detail, the email address, the tax IDs, Social Security numbers, all of those items would get replaced but with a realistic looking value. So a name is still a name, and it still contains segregation according to gender and the country of origin for the record that's being processed. Similarly with the banks for where you have different formats for different countries, for different states, for different banks even in certain cases, we would maintain that integrity. So during things like payroll on the HR where there are validations run off, is the banking information correct, that we will provide data that is fitting to be able to to process that. So as I say, we pseudonymize after the copy, or if you were to use our software, you'd be able to do it during the copy. But first, we need to work out what's the risk and what do we need to do, and that's gonna be the first stage. So we always talk about our road to compliance to be able to look at what we're going to do, and we've got sort of a wheel of pillars of the the main items that every business needs to go through regardless of industry to be able to understand. And the first thing is the impact and risk assessment. Don't think I need to explain that any further. You have to know what your risks are. There are many partners out there. This is far broader than just technology. This is looking at paper management processes. This is looking at do people lock their workstations when they walk away from their desk in the office. All of the different protection method methodologies and securities that you need to put into place would be subject to a full impact assessment. So we work with those partners on the technical side to then say, for your SAP estate, let us go and find and map the personal data that you hold. And we've got specific software to be able to handle that data discovery, to be able to find not just the standard items that like I say, we've been we've been doing this for twenty five years. We know where the business partner data is. We know where the customer data is. I'm going to show you that in the system in a moment. But because we know that, we also know the technical makeup of that data. So from an SAP technical point of view, we understand the data elements associated. So we can then search your data dictionary as a wildcard to also find anywhere that you've created a zed bank field within a zed table or within a standard table as an extension. We can report all of those out. My privacy delivery team would then come and do an analysis based on that within your system to be able to map those customizations back to the standard model where they integrate, how they need to be linked together to keep consistency after scrambling, and perform a workshop with you to discuss what you do want to scramble, if you have any filterings, if you have any specific transformation requirements for the how things would be processed. We do have our standard offerings, but we can also customize those based on your needs. So we can do that full discovery. We then work with one of our partners, Ceterion, on who can access that data. They have a specific privacy rule set, so this is a light GRC solution. And we're able to then do an analysis of both your production and nonproduction systems to be able to understand who can access the personal data and is that appropriate. Again, do you have cross border access? Do you have the the right sort of traditional use of segregation of duties and access risk and elevated rights? It's a complete solution, but with a specific component arm that's focused on data privacy to ensure you've got the right items. And then we get to actually doing something about the bringing up the compliance. So we found it. We know who can access it. We come up with a plan of how to resolve that. Quite often, the first request is I need to clean up my backlog in production. I've been running SAP for twenty years. I've got a ten year IRS rule as my greatest legal challenge. From that, I want to be able to remove the previous ten years data safely. And, again, we've got technology to do that, and we would work with the team on a on a go live to be able to to get clean from that point of view. And then your nonproduction landscape to be able to say, I now need to get rid of the personal data from my test systems, and that's gonna be the example that I show you today for the Data Secure product. I already mentioned as well that with many of these privacy laws, we have the subject access requests or DSARs becoming a part of the common items. With the same data map that we've got, we can then use that to pull the information for a particular legal person into a PDF, put that into a formatted output document with your branding, with your logo, and some standard introductory text and terms and conditions associated so you can quickly respond as a front office process to access requests. You need to have the selective data removal process for if somebody requests the removal and you don't have a legal justification to keep it. If you think you've got a lot of data that's going to time out, then you want a proactive approach to actually say, let's find the data that needs to be removed and move it into a business process where it can get safely removed from the environment. Again, we have a solution for that to be able to assist. And then the other key point that we always make here is that this isn't just a one off activity. As you're moving through s four migrations, if you decide to buy additional third party add ons, as we explore the AI age, as the privacy laws continue to change because of all of those other factors that are going on, You're going to need to make this part of your change process to say whatever you implement to be able to anonymize data in your test systems or remove it from your production systems, you're going to need to keep that up to date as your data model changes and as your business, moves forward. So working with your audit teams, with your change controls teams to embed privacy as a core tenant to, your your solutions. So that's a a fairly lengthy description of the problem space. I hope that there was something new and interesting in there that you possibly haven't heard before. I'm now gonna move forward with what do the products look like. So we have two software sets or suites that we're going to focus on. So Data Sync Manager is our test data copy, and we have a solution called System Builder or Shell Sync, which is for building systems. Client Sync, which is for refreshing clients but with reduced data. So, again, the privacy linkage there is many of the laws talk about having a proportional dataset for the use that's required. So why do full system copies of twenty years' worth of data if you only actually need the last quarter to be able to complete the testing that you're trying to do or the last financial year to be able to run financial year end. You can reduce and, obviously, there is a a financial benefit there on infrastructure of lower size test systems. So Client Sync is the data refresh tool that allows us to bring data from production. Object Sync allows us to to provide data on demand. So in between those large refreshes, you're able to pull a specific customer vendor employee with all of their related data and move that to your target environment without needing to do a full instance refresh. Data locate is a relatively new solution that's been built for linking with WorkSoft or Tricentis for test automation where we can find keys find object records that are needed for the test automation tool to know what data it needs to use to be able to run its automated test script. And then Object Extractor is the the software component that allows you to extract that data in a format that can be ingested by Certify or Tosca and bring that bring that data into the environment ready for the automation script to work. So it allows you to further automate your testing with real quality production data, but all of those components that I've just mentioned then have Data Secure embedded in them. So if you are extracting for Tosca to be able to do a process, you can anonymize the data that's going into that into that extraction to make sure you're not creating more personal records in your test system after doing the scrambling. Similarly, with Object Sync, when you want to do a data copy on demand, you can use Data Secure to be able to anonymize that data in flight, so you never start adding the real data back into your test systems. So Data Secure exists in both of the suites we're gonna talk about, but the rest of Data Sync Manager is about your test data management and testing automation to be able to link together, and Data Secure is where we're focusing in today. And then the data privacy suite is then the production aspect and nonproduction, but focused only on data privacy. So if you don't need a client refresh tool, you don't need an on demand data copy tool, you don't use test automation, You don't have to have the full suite of the TDM suite. You can just have Data Secure if that's the item that you need. And similarly, if you do have production concerns where you want to be able to safely remove data, that's the Data Redact tooling. And our differentiator on Data Redact versus ILM from SAP is that we don't try and complete an entire record deletion. We're selectively removing only the personal data from the record. So it doesn't affect your database size by any significant measure, but it also means that where you have those funny scenarios where you can't delete a customer because there was a sales order ten years ago that's in the wrong status, and you'd first need to run a cleanse program to try and fix that status before ILM and SARA and the logic built into there will allow you to do a complete deletion of the record. With redaction because we're going to leave the customer number there, but just remove the privacy data. You can be compliant without those concerns. We did have a recent customer that that gave us a testimonial where they said that they'd identified quite a large amount of data that needed to be removed, and they could actually only remove 20% of it. 80% was blocked for items that they were now having to go through a cleanse project to try and fix before ILM would remove it, and we're currently exploring with them whether Redact is a more appropriate solution. And then data disclose is the access request, putting everything into that PDF, getting it to the client, and data retain is our automation tool to be able to identify data that must be removed. So we build your retention logics based on the time period, based on the characteristics of the record, based on the country that they're from. Our most complex account for retention was actually with Nestle. They're a success story that's on our on our website that you'd be able to access where there was over a 100 individual retention requirements for all of the different countries that they're in because of that differentiated privacy laws that they're having to adhere to. And then, obviously, Data Secure is a part of this suite as well. So depending on your problem, we have the data handling solution to be able to to assist you. But like I said, Data Secure is where we're gonna focus in today. So it's deployed directly to your environment. It is something that processes within the ABAP stack directly, so within your database. So there's no new external security concerns created. If you do have a linked SuccessFactors, then we process via the OData API provided through your basis team, through your support network to be able to create the OData RFC from the SAP side. So everything is controlled within. It's provided with segregated roles and duties, to be able to ensure that you can split who's doing what. And when we have modified the data, so after this the scrambling is complete, it is a direct replacement of the information in the database. So it's not like UI masking where the data still exists, but it's just hidden from somebody that tries to access it through the UI. This is something that is actually changed in the database. So even if you had an external breach, a theft, a hack, a ransomware, and they got one of your nonproduction systems, you'd essentially go, so what? It's all random data. It's not the real thing. They wouldn't be able to do anything with it. So it's a complete change up from the sort of masking side of things, and it's scrambling the or pseudonymization that that we're completing. Okay. So I'm gonna show you now within the systems what that actually looks like. So to start off with, I would like to show you our one of our development systems, and I'm just gonna talk you through what comes with the product as standard. So to be able to do everything I've just described, all of that data copy, slicing of data, getting time slicing correct, performing a copy of just a specific object, we've had to build our own object definitions to be able to support that. And we have couple of thousand of these now as object definitions that cover everything for ERPs, so s four. Technically, do have solutions back to four dot six c all the way through to the latest s four. There are some restrictions on a four dot six c that you can't do everything because we don't have all of the toolings. But we also cover the CRMs, SCMs, SRMs, GTS. And within these solutions, you were to have the student solution or if you had IS retail, oil, utilities, we have specific objects built to be able to handle all of those. But when I say an object from our point of view, what do I mean? I'm going to use the business partner as the example so we can think about it from a s four view, from what is the current the where's everybody moving to, mainly because it's such a heavily integrated object. So the business partner or or any object that we have has the same basic structure. The first table that we've identified in the system would be classed as the check table. So this is where we can find a single entry that has the primary key, so in this case, the partner number, and has a single entry for it. So for the employee, it would be in for type three. For vendors, it's LFA one. For materials, it's MARA. For customers, it's KNA one. And then we link to that every other table that we would need to consider from a data copy point of view to be able to find everything that should be integrated. So for the standard sort of banking information table, BET t zero b k, we have the mapping that it's on the full object key, the partner number. But if I come down for an s four system and we think about the CVI, here, this table links on the partner GUID, not on the partner key. So we've mapped them out for all of the related tables to be able to make sure that we have everything that you'd expect with change documents, with purchasing data, with CRM data, etcetera, to be able to map out all of those table relationships. So we've got a complete view of what makes up a business partner. We've then built integration points, which allow us to say, how do we find a related object? So we used to call these is a integrations to be able to say, this business partner is a customer. How would we know that? Well, within the actual integration point, we've mapped the table and the selections that you'd need to make. So the partner number goes into table b d double o one in an ECC system, and then you would find the KUNA within that table structure, which is then the main link to the customer record. But these can also go cross system. So from SRM to an ERP vendor, the we understand how that there is a table in SRM called VEN map. In here, you would pass in the partner number, you'd find the vendor number, we would cross to an ERP system, and then we can find the vendor object on that side of the equation. So we have, as you can see, quite a large number of these sort of integration points, and this is just one object. And I say there are thousands of these objects to to map through. And it's not just master data. We've got the transactions. If we think about the sales process, we've got everything that you would expect for inquiries, quotation, sales docs, shareholder agreements, contracts, delivery, shipments, build docs, etcetera. So it's fully mapped out, and the object allows us to say, these are all of the tables that would be of concern for that data, and these are all of the other objects that would be integrated together. But then, to be able to process anonymization, we need to go a step further and actually map it to a field level. And this is where we provide what we call integrity maps. So an integrity map takes it down to that level of understanding the exact field that we need to process. And again, I'm just going to continue with the same example, a business partner, and we're just going to talk about a name. But again, you can see here that this is a lengthy list just for the business partner, and we've got all of the other objects that you'd expect mapped out as well. So with a name, we don't only map to say, I want to process the b u t triple zero name first field in this case. We map to be able to say we know that that business partner will have an address, and that address will have a name one field and a match code, an MC name one field, and that needs to be an uppercase mapping of whatever we've done to the related key. We know that that business partner might have a customer, and that customer will have an address, and they'll have some banking information, and that will also have the name in involved in the coin h field. Similarly, the business partner might be a vendor, same thing. The we've mapped out those integrations down to a field level that we know that an employee InfoType two Varna is the same as a org model HRP 1,000, the e name, s name, is the same as b u t triple zero name first and name one in a d r c k n a one, etcetera. We know that they're all the same. So when we anonymize, we don't just anonymize that single item. We anonymize everything consistently to keep it together. So our integrity maps take us down to the field level, and this is where our discovery logic comes in that we can use this as the initial data map. We can expand that search out for anything that is related to the standard data map and find those zed customizations or third party tables that are using the same data dictionary elements, pull that information together, review with you, and then during our implementation of our software, we would extend our product in your environment to be able to cater for all of those customizations. I'm now gonna switch to one of our demo systems with with some actual data so that I can show you what this then looks like. Because, obviously, what I've shown you there is fairly technical, but I want you to understand what is in the product out of the box. How does this how do we do everything I've claimed that we do? It's because we've got this configuration mapping down to that field level, all of the integrations already mapped out. So we then collate all of that information together that we have transformation functions, which is how you're going to transform. And these are wrap up programs. I'm not gonna dive into them purely because of time today. But as I mentioned earlier, things like names still consider country and gender. The ID numbers, we know the difference between a MXN in Mexico and SSN in in The United States, and an SIN in Canada, and we know how to format them correctly, get them updated, and keep that consistent between multiple systems, between multiple objects within a single system. So the transformation function is there how we're going to do something. The rule is where we collate those informations together, and ultimately, we move to a policy, which is the thing that you'll actually execute. So we do have a standard delivered policy that we provide out of the box. And you can see here it's fairly broad that we've got transactional data, accounting documents, GRIR docs, CRM loyalties, items, FICA for some of the industry solutions, and the main objects that you would expect for the address, the business partner customer. Our employee can be processed as a central person, so again, if you have international assignments, if you have concurrent employments, we understand that they're actually the same person, so we would link them together and ensure that they still had consistent data after scrambling by using the central person as the main object rather than each individual perner from an employee point of view. And contained within those objects are then the rules. So you can see here for the business partner, it's your ID numbers, it's your tax IDs, it's your name, it's your banking, and it's your address. So all of the things that you'd expect to see and sensitive dates, of course, sort of date of birth, date of death is also stored against business partners that would be handled. But if we just look at one example, so I'm gonna look at the the names rule for for the business partner. We provide a couple of options in this rule. Now at run time, the user could decide that in one system, they want to change everybody's name to John Smith. So they can choose the option to assign constants. But, in a different system, you might want to scramble. So if you wanted a different rule in your training system compared to your development system, compared to your preproduction system, compared to your sandbox, you could have different options, but still only one policy. You've only got one thing to maintain, and then the execution has the run order of which option is gonna be used. And then within an option, you can take things down to what we call a conditional level. So for the business partner, there is a specific field on the business partner that identifies whether the business partner is a person, an organization, or a group record. And depending on that classification, it's different fields that will get populated. So through the use of conditions, we're able to understand the context of that record that we're processing. And where it's a company, we will process the name org field, and we'll process it with the transformation function of a random company name. If I scroll down here and we look at the condition group, so a type three, then it's now the name group field rather than the name org field that would be populated, and we'll make sure that everything else is cleared down and we've got a random company name in there. Or in the final condition, which is where it's a person, we then have all of the individual fields for name first, name last, name middle, and they're being treated with first name or last name. And again, as I mentioned before, considering the country and the gender and how we integrate them together. So you keep a very high data quality of the information that you're that you're scrambling, but and you keep the same production scenario in terms of what they've done, what they've sold, what they've bought, what they've been paid, but we will go in and we will change all of the related data to to be able to come out to a consistent value. So you pull together your policy is is where we would end up. There's a few examples, zed policies here. I'm not gonna dive into those. But for each of you, our implementation service would be all of the technicalities we've just spoken about, mapping those customizations, coming up with specific filters that you need to apply to only process where it is a person record. Your rule may be that you don't want to process anything that's a company or a group. That's fine. We would filter out those records so that we don't process them, and we only process the business partners that are a person. And we would configure that to be the right policy for you, and we then have two execution options. We have one to mask objects and one to mask the entire client. So the client, this would be a basis activity. You would pick your policy for the item that you're going to use, and then that's the one I'm gonna use today is our default delivered for employee. You would set your execution options, so how many parallel processes you want to use, any scheduling, if you want to receive notifications on the job while it's running, and that's it. So all of the technicalities that I've just shown you is actually the implementation and the management of the policy. The execution for the basis team post refresh is to come to the client mask, choose the policy where there's likely to only be one. It would be your policy that you've defined, and then choose the technical processing of when should it run, how many batch processes should it use. Well, for our example today, I'm gonna process an individual record. So I'm just gonna go to Infotech 20 here, and we're gonna look at the record for Sam Jones, who's a US paid employee. She exists in this environment. Across to SuccessFactors. Sam also exists in there. The we have Sam Jones. Once it's loaded here, I need you to log me back in. Let's just do that again. There we go. And Sam has been living in Hummingbird Lane. We're within Bryn Mawr in Pennsylvania. We have the Social Security ID, etcetera, and that's all consistent between the systems. So I'm gonna select that I want to scramble just that one record. So I'm gonna use our central person object. I'm gonna say that I want to scramble that personal ID number, so and the. I can then see what has that found. So it's found the employee record associated, but there's also payroll history, so we need to update the clusters. There's also the SuccessFactors record. There's a personal address associated. So those integration points that I showed you before have now fired and brought all of the information together. And we're then gonna execute this policy. It only takes a quick minute, and it's only one record. So I'm not gonna use any parallel processes. We'll just bring that through. So I'll just exit the record there. When we have a running job, we're able to see what that job is engaged with currently. So if I just go back to one of these previous runs, we can identify the objects. We calculate the new values. We have updated values during the implementation. We also have audit controls. So this is a separate role within the the role authorizations, but we can actually see down to a field level what's been calculated. So in in this run, the Hummingbird Lane was to become under cliff. In the next run, the one that's running right now, this is gonna be a different value. But we have the audits available to be able to show us what we do have. So the the execution we're doing right now looks like, yeah, it's just finished calculating the records. So we can see now here that in this case, we're going to go to 1912 Torresdale Avenue. So it's a real address, but it's a different address to the one that was in the previous run. So we don't have any patterns here. It's not always reusing the same values. It's just bringing through the correct items for you. And I'll just wait that to finish yet. So we've updated. So if I now go back to PA 20, we now have, instead of Sam Jones, Clara Mae, Gully, if I was to look at the payroll results, they would also be Clara Mae, Gully. Obviously, where we had the Social Security, We we still have one. It's formatted correctly, but it is now well, in fact, because I haven't refreshed, I can show. So it used to be 122-89-7512. It's now the 493-41-4953. But if I now refresh SuccessFactors, because this is an integrated system, Sam Jones has become Clara May Gully. We have the same address on Tarsdale Avenue, and we have the same ID number being created but in the right format. So it still passes all of the validations. So the solutions are built to be able to perform this level of field level integrated data anonymization, but it leaves you the data quality. You still got the payroll history. You still have the sales history for your customers, the purchasing history for your vendors, but you don't have the personal data risk. And that is the principle of the Data Secure solution. Okay. So before we just have a small chance for a couple of questions, the final couple of slides here, we have a free DSMR assessment. This does a high level check for personal data. It's not the full workshop. It's not the full sort of requirement gathering, but it gives you an indication of how much custom PII you might have in your environment and how much of it we cover as standard. So that free DSMR is held under this QR code here. You'd be able to request that from us. It's a transport you can apply. You send us the results. We load it to our client portal, Client Central, and we would then have a meeting with you to present those results. Or we also have the full privacy workshop here, and this is a five day, five mandate exercise. Normally, elapsed time is around about two to three weeks depending on your team's availability to be able to run a full analysis, not a quick presales analysis, perform manual analysis in your environment as well. So we would need to be onboarded, have a VPN access to an environment, and then run those workshops and produce the output document for you. And, again, if that would be of interest to you at this point, the QR code here will link you straight through to a website where you can get to that. Very briefly, we've got Oklahoma Gas and Electric as a success story that was recently completed for the anonymization. The full details of this are on our website, and you can gather all of our success stories from there. But looking at the time, I'm not gonna go through it in much more detail, but you can see that that it was SOX privacy needs, and the nonproduction was the main driver, not that production side. But they needed the data to still be related. And in this case, because it had ISU data model even more so because the meter is linked to the address, is linked to the person that's being billed, You have to maintain those relationships to actually be able to run the processes. So it was a successful project that you'd be able to read more information on our website. You can see here there's a few upcoming events that we're going to be attending, that we've got some speaking slots, and we're also gonna be sponsoring booths. If you're gonna be at any of those, please find us. Come and ask questions. We're gonna have a team available that can answer questions for you. And finally, should there be anything that you wanted to discuss further, you've got my details there as the service delivery, but also our director of ALM sales for The United States, Dan Bankman. If you wanna reach out to us, like I say, we will follow-up with you as well Carrosoft, and there's also the link there for the success stories. So we're gonna share these slides with you along with the recording of the session that you'll be able to to use those links. Okay. So with that, I've left us four whole minutes, Josie. I've talked a little bit longer than I planned. My apologies. But, hopefully, that was interesting for everybody. Have we had any questions come in that I I can answer? Yeah. We do have a couple questions. Any questions that we don't get to live, we will be sure to follow-up and answer since we are a little bit short on time. But the first question that we had was what if sensitive data exists across multiple systems, not just SAP ECC? Okay. Perfect. That's Jesse. So, yeah, it's always an interesting question. So I I already mentioned about sort of CRM, SRAM, SCM, and in the demo there, you saw the OData connection to a cloud solution. We have now expanded a little bit further as well. So we have a a a new cloud product on the market called Symantik Shield. With Symantik Shield, we're able to connect currently to Workday and Salesforce. So if you're using Workday as your onboarding training solution, but still using SAP payroll, we can keep the data consistent through anonymization that the employee records still link together. And similarly, if you're using Salesforce for your CRM or SAP still is your finance, we're able to keep that customer data consistent between the two. It slightly changes the approach because we have to be able to share some mapping information to keep that consistency. And, obviously, it's a cloud solution that would require external availability, so that has been built with the ISO certifications, etcetera, in mind. But for standard SAP, we process via RFC. For this SAP cloud applications, we would process via the OData APIs that are made available, and then our Symantec Shield solution is able to use all of the API methods, whether it's SOAP, whether it's REST, whether it's OData, whether it's a direct database that we can go and access. Symantik Shield allows us to integrate and consistently anonymize all of those applications together. As you can imagine, it's just slightly more a little more work to map out and make sure that everything's consistent for you afterwards. Awesome. Then it looks like we have time for one more. How do you protect sensitive HCM and payroll data without breaking the relationships needed for realistic testing? Yeah. So that's ultimately where the the approach of the pseudonymization comes in. That we we need to leave that referential key of the perner, the central person, the rel ID going into the payroll results or the change cluster, the all of those key value items have to remain the same. We also very strongly recommend that you wouldn't modify something like the salary values themselves. Because if you were to modify salaries, the next time you run payroll, it's gonna automatically fire retros, which is then gonna be a significant recalculation because we've changed all of the salary values. And if you've de identified everything else, so there is no family member linkage, there's no names, banking, telephone numbers, etcetera, dates of birth, then typically we find that the salary can be left alone to be able to maintain that integrity. But we do having said all of that, we do have a rule that will anonymize the salary. It is still just fields in a table between a few different info types that can be updated. But then if we were to do that, we then need to discuss how to manage the payroll cluster. So do we reset the configuration on retros so it will only look at the last month and it won't go into history? Do you want to rerun retros and just have that as a post processing activity? Or in some cases, our clients actually say, let's delete the payroll cluster and just start from fresh and reset the start pay date to one month ago and rerun payroll, but with the scrambled values. So there's a few different options and ways that you can sort of manage the process, but by maintaining that referential integrity and not attacking the key value, it means that you can still have that real data identified and brought in to have the true data scenario just instead of James Watson, it will be called Bob Smith. Awesome. Thank you. Then that brings us to the end of our time. Thank you everyone for joining us today, and a special thank you to James for sharing his insights and expertise. We hope this webinar has been informative and valuable for you and your organizations. If you have any additional questions or like more information, please feel free to reach out to our speaker or the Carahsoft team. Their contact information is currently displayed on your screen. Thank you again, and enjoy the rest of your day.