Einhaltung des Datenschutzes: Ein Einblick in Ihre SAP-Daten

Good day. My name is Jones Watson, and today I'm gonna talk you about, the privacy laws that we've seen coming through recently and the impacts they've had on businesses and also how you can get started on your privacy journey towards compliance. So to start off with a little bit about myself, I am the commercial product owner of our privacy risk and industry solutions here at EPI-USE Labs. I've been working in SAP for a couple of decades, where I started off within the utilities industry, working with SAP ISU, and moving through into full landscape data management. And architecture, over the last sort of six to seven years. I've been looking after the privacy solutions for Europe since the advent of GDPR in twenty eighteen, and worked with multiple clients, and of course now with the global laws starting to come through, we're seeing those impacts across different regions. So hopefully I'll be able to give you some interesting information today. That you haven't heard before and give you some suggestions on how we can move forward. So to start off with Let's just take a little view of how these privacy laws have actually impacted our businesses. And the first impact is quite obvious. Going to be financial. And if we just take an example of the United States, we can see here that there are multiple multiple million dollar fines that have been processed under the terms of GDPR and in California there, Sephora's first CCPA, enforcement that was put into place just last year. Additionally, taking Italy as an example, we have lots of large telecoms energy providers that have seen some very, very large fines that have been brought against them. So there is high monetary value, being fined within these different countries. But additionally, to that, we get the reports of, these fines going into, the, the news and social media and they're then generating additional requests for access from these companies, under the subject access request. So you have reputational damage, you have financial damage, and, overall, it just puts your business into a bad light. And therefore we need to look at the ways that we can try and address these issues so that if there is a data breach, you have minimised and taken all of the best processes that you can to be able to move forward, without large damages to the environment. So how do we see our businesses going around this after doing, technical implementations for privacy solutions? For a number of years now, We see that it actually boils down to a very similar approach that regardless of industry, regardless of country, you have to go through these same sort of core steps to be able to reach compliance. So the initial item is just impact and risk assessments. Sounds obvious, but of course you do need to understand what both your business processes and your, technical risks and impacts are, and it is important to think about that business processes side rather than just the technology. Common example I talk about is, where you have a contact center staff or front off staff taking phone calls, and they have a notepad where they're writing down personal details about individuals as they're taking calls. If you don't have a process of what happens to that notepad, that is also a possible bridge if that notepad leaves with the individual at the end of the day. And it gets moved, out of your company's control, you are taking personal information about clients, employees, etcetera. And, allowing that to leave the premises in a non controlled way. So you have to review both the business and the technical items. Obviously, as a technology provider, I'm gonna focus more on the technical side. And now for the next step to be able to look at that is to be able to find and map your personal identifiable information. And that's gonna be searching through your IT estates to be able to understand where you hold the names, telephone numbers, email addresses, bank details, etcetera, and, mapping that out to be able to have a full data risk assessment. So then you can start planning what you're gonna do about it. And you will also find that you have systems that, are subservient to something else. So in our example with SAP, we quite often find the Oracle solution Tullyman, for example, for debt collection. Will sit downstream of SAP and will pull its data from SAP. Therefore, by fixing the SAP problem, you also fix the time on problem because it will automatically pull through those updates. Whereas you might then also find other appliances, some of the cloud applications that are being used now that require a push from SAP to the cloud application in order to complete an update or a direct integration and API sort of technology. So we typically find our clients move to a traffic light system where you will have red amber green in terms of the volume of the PII that's in there and the control method that you have. Red being your highest risk, amber being there is data, but by fixing one of the higher risks, it would already fix that. And green you simply have a system that doesn't contain PII. You have never put any personal information into that environment. Once you've got that map of the writ of the PII, you then need to understand what's the risk that's associated to it. So in a technical terminology, that's gonna be your security access controls. So how difficult is it for somebody to be able to get to that personal information. Do you have appropriate segregations in place from a SAP point of view? Do you have super users that are able to do table access to any table in your environment and therefore can pull all of your HR, all of your finance, and all of your, customer vendor. Data into files and perform an internal data theft breach, etcetera. So you need to be able to review those access controls and understand where you are. It's quite a lot of work to be able to get to that stage, and that's what I'm gonna talk through in a moment of how we can help simplify that journey for you. Following on from that, we get into doing something about it. So we've understood the problem. We've mapped it, and we've looked at who can access the the the data. So you then have the process of cleaning up the backlog in production. So this is getting rid of data that you no longer have a legal notification to be able to retain in your environment. We then need to think about what about when you copy data, so most companies will have a testing system, a development system, maybe a pre production or a training system where you're copying the real data from production. You do need that data to be able to do accurate testing, to be able to ensure that you don't only find issues in the production system when you are applying changes, new processes, etcetera. But you don't have, in most cases, I'm ex informed and explicit consent for the use of client vendor or employee data for the purposes of testing. And as such, you have to be able to modify those through to be able to say, which items are sensitive, which items are non sensitive, what can you copy, what can't you copy, and if you do copy, can you anonymize to remove that risk and how do you control that process? We then have subject access requests. Of course subject access requests are not a new item. They've been around since the the laws that became popular in the nineties. And, what has changed is the level of enforcement and also the time scale to respond to those rights to access. The other thing that we've seen that's changed is the popularity of them that because, GDPR has been newsworthy, and people have found out they've got these accesses. We've even come across social media groups where groups of individuals are getting together and targeting individual businesses to say let's all go and request a ride to access from these and see what how they respond. So the older, sort of typically manual process, maybe a small program that'll pull a few things together, becomes quite unusable if you're gonna receive a thousand requests in a month and you have to have a better way of responding to that right to access. We then start to talk about the individual removal. So we've done the whole backlog, but now what happens if you get a functional request? That somebody calls you tomorrow that says, I was I haven't been employed for more than ten years. You still hold my information. Please get rid of me. So there's both a compliance legal view to this to be able to say what rules and checks are gonna be in place for when you will accept a request for our deletion. But then also you need to think about the technology of how you're gonna remove that without affecting all of the other data that's in your environment. We then have proactive identification. Again, this is a new tenant within a large majority of the global privacy laws to say that you must have proactive retention management on personal data. You no longer have the right just to keep that data for, for all time. So you've taken care of the backlog. You've got individual requests for access or for removal. We now have at data retention process to say, I will automate this, and I will, automatically find data subjects as they fall foul of our retention periods that I no longer have a legal justification to retain and therefore we will automatically do data removal and improve our overall compliancy position. So then the final step is to be able to consider that it's not just a one time process for privacy. It is gonna require an ongoing review, and you're gonna find yourself going around this circle a couple of times. Because as you continue to develop, you will have to, possibly purchase new appliances. Put just new, third party add ons that you're gonna add to your SAP estate, looking at your S four journey and then looking at cloud application, and how we're going to integrate and share data between those. It's not going to be a one time thing, privacy needs to become embedded into your business process. And trusting your auditors, finding trusted privacy technology partners, as well as having those responsible data protection officers within your business is paramount to maintaining this compliance moving forward. So if we focus in on those first couple of steps of understanding how do we find and map the PII? How do we understand the security access risks? And build that overall risk map, that is going to be your business case for what you then need to do. I wanna start by talking about SAP standard, and just giving the scenario here of a fairly typical scenario, of you have an employee that exists in your, SAP system. That employee works on some projects, does some travel, and incur some expenses that they claim from the business to repay those SAP puts your employee data into a vendor record. So they can be financially processed. If you're utilising S/4 or business partners within ECC, that vendor could also become a business partner And again, in terms of tables of data, it's replicated again into a whole new set of tables. If that employee was to purchase something from you, if that's appropriate for your industry, you would also then get a linked employee with a vendor with a customer customer and their related business partner all linked together. So that starts to create a spiral of tables where all of the a sensitive information that you've captured is proliferated throughout the SAP environment. And like I say, that's still just the standard tables. Over the last number of years, you will have customised your solution. You'll have created, specific functionalities and they will then, the have been built in what termed as z tables or y tables in the custom space. Or potentially you've purchased, a third party add ons again, and they, again, need to store the data from your vendors to go into the VIN process for vendor invoice management, and that will I replicate the same names, telephone numbers, bank details into another set of tables that need to be handled. Trying to go and map where all of these are now is quite a challenge. So what APU's labs have done is we have initially done a mapping exercise. So we've been SAP partners for a couple of decades now. And we've already mapped the standard data model to allow copying. What we've now done is map the individual field levels into something we call integrity maps. So in this example here, we have a name that is identified not just between different objects, between the customer and the business partner, but also that is mapped between systems between ECC, a CRM, and a VW. So you now know if you identify that person, that key at somebody that needs to be removed, you don't only need to remove it from the ECC customer, you need to find the CRM, a business partner, and the BW zero customer, and make sure that the data removal is completed in all of those areas. Otherwise, you are still retaining the personal data for somebody that has requested removal. So we've got this mapping of the standard But as I mentioned, you'll also have a lot of customisations, and that's where our technical discovery and workshop consulting comes in. So from that mapping, we, can use the data dictionary provided in SAP to be able to do a search of your environment which, takes those common, personally identifiable pieces of information. And does a wildcard search be able to identify anywhere they've been used within the z content, within third party content, and prepares an output list for some detailed analysis by our services consultants of both the standard and the custom tables. We will then do an analysis of your system where we will deep dive on to those tables and understand how they connect to the standard data model, how, the what functions could be taken to be able to anonymise them for non production or how to be able to, optimise them for data removal. In the production instance. And where we end up is trying to build a short service typically running around about one to two weeks per system depending on the complexity that you have. And as well as the analysis, we will perform workshops with your, business teams and your legal compliance teams to be able to arbitrate between the requirements of legal compliance wanting to remove everything and the business team's needing to still function. And how we fund that middle ground together. We'll share our experiences with our other clients to be able to help inform on how what challenges have been faced depending on the requirements that we're hearing and help inform the best way to be able to move forward. Ultimately, thing gets documented into a report for you. This report contains both the business requirements from the workshops, but also the technical discovery so giving you that PII map that you're able to then process through. But the other stage that I mentioned was around the, the access to personal information. For that, we have a partner company called Soterion, who we work with on a regular basis where they have particular deliberate, rule sets that are able to be used as part of our enhanced discovery process. So the first item is to be able to look at privacy data risks so that who can access those privacy data items but we also have segregation of duties. And with the segregation of duties, you're looking at who can process both a request for payment and actually authorise the payment and process that through the environment. There are delivered rule sets to look at the cross legal jurisdictional access. So data sharing between the EU and the US, obviously brought very much into sharp focus recently by the, very large billion dollar fine that's being leveraged against, one of the social media companies, fall into region share of data, between the EU and US. And of course, there's also critical transaction risk. So these are your super users, the the the the users that are able to access For possibly good reason, a large majority of the dataset, but when you put the privacy angle on it, is it correct that they're able to do that? So that now we would include not just a, a one stop shop, view of that, of that data, but a one month license to the criterion, to the criterion instance for your data. Where you're able to do some analysis modelling and see what what would change in terms of The the potential risk versus the actual risk that's in your environment and how you could then process it through to be able to reach a more stable and better set of data. So with these discovery solutions, there is no license fee. There is some services cost involved to be able to come and do the analytics and prepare for you. But we're not looking for large capital investments. It's gonna be a OpEx cost that could be reviewed, against the business value that that's gonna provide. We could the output report can be used to be able to present with auditors or if you were under review by any of the governing bodies for privacy laws you can show them that you've already started this process. You have your map. You understand what you're going to do. And of course, then the final thing is what you're then gonna do about it. And we're not gonna step into this in detail today. However, when we then talk about the different solutions that are available out there. EPI-USE Labs provide the s the data privacy suite for SAP. This contains data secure, which allows non production scrambling. That's direct anonymisation of data within the database, so not UI masking, we're not hiding information, we are physically removing the PII from your test system, but in an appropriate way that still allows your testers and business users be able to use the system. We have data disclosed, which is the response to the right to access, where we use that same data mapping, but pull the information into a password encrypted PDF that can be shared with your clients or employees via email, if you wish, or via print, and, and and central mail. We then have the data removal side of things So data redact, which is the processing engine that controls what's gonna be removed. This is restricted to transport management with additional control rights to ensure that, administrators need to approve any changes if they're going to production. But it maps out all of the data that needs to be affected and then completes an actual clearing or constant value replacement where a field is mandatory to be able to remove that personally identifiable information, but without the need for full deletion and archiving and, for example, if you have financial records associated to employee vendors, If you delete the employee vendor, you also need to delete the financial transactions, otherwise the system would have an inconsistency. With our redaction approach, the employee record remains, the vendor record remains, but the personal data is removed. Therefore, the referential integrity of SAP is retained and you can keep your business data of the, of the financial information associated or without any of the privacy data risk. And finally, we have data retained, and data retained is that proactive identification of data. It allows us to search the entire SAP S data on rule based validators to be able to identify a list of things that no longer have a requirement or a legal justification, should I say, for retention, and we'll then submit them into the direct action process. You can have multiple policies between the retention and the reduction to be able to remove different data at different periods of time. Depending on the the laws and the business, legal justifications that you have for data retention. I hope this was interesting for you, and it's helped give you a view on where your options are on how you can move forward on the privacy journey. If you do have any questions, there's some contact details on the screen here. Please do reach out to us and we'd be happy to talk with you. Thank you.