2026년 SAP 데이터 프라이버시
현실 점검 – 3가지 주요 오해와 진실

Good morning everyone and very warm welcome. Thank you for taking the time to join us today. We're really excited to have you with us this session twenty six Reality Check, our top three SAP Data Privacy Myths Exposed. If you've ever thought our production system is secure, so we're compliant, you're definitely not alone. But as we'll explore today, that assumption, along with a few others, could be putting your organisation at risk. Data privacy regulations are becoming increasingly complex and the reality is that compliance doesn't just sit in one system, it spans your entire SAP landscape. Today is all about challenging some of those common assumptions, unpacking where risk really hides and giving you practical insight into what you should be doing next. Before we get started, I'd like to hand over to our SAP landscape and data management specialist, James Watson, who'll be running the panel today. James, over to you. Perfect. Thank you, Amy. And yes, good morning, everyone. So today we've pulled together a few of our experts. We're taking different roles within the company, but all with a focus on data privacy and compliance. So I'm James Watson. I run our global services team and also manage the specific products that we have developed at EPI-USE Labs to address privacy needs for SAP clients. I'm joined by Johan Hafel, who is our Chief Information Security Officer here at EPI-USE Labs. Danny Lutz, who works as part of our advanced IO team in custom development building applications that have to adhere to these guidelines, and Rohan Ramji, who is one of our regional architects assisting in service delivery and in architecting the solutions that businesses need around data privacy. So to start off with, we wanted to give a little bit of history and background to be able to say what has changed. So back in twenty eighteen, we had the launch of GDPR, which everybody is aware of, in Europe and also the LGPD in Brazil. Now, weren't the first privacy laws to have ever existed. Obviously, we had some privacy laws from the 1990s that had similar requirements for businesses, but in general, far less teeth to the laws in terms of the enforcements that could be leveraged. But also these were far more updated for the world that we're now moving into of big data, of data share, of obviously, even things like Google, Facebook, or Meta. They didn't exist when the nineteen ninety laws came into being. So it was a good update to the handling of data within businesses. But the global landscape has continued to change quite rapidly since then. So fast forwarding sort of six years to two thousand and twenty four, we then started to see this picture emerge where there was around about ten American states that had done a similar privacy law or were in the process of doing it. We'd had POPI through in South Africa, the DPR in Kenya, and including through in China and Asia, Thailand, South Korea, where we had a few new laws coming through in those areas. So it was starting to get quite complex already for those larger organisations. Now going back to just maybe three or four weeks ago, where we had another look at this to be able to say, what does it look like now? So there's additional states within America Mexico, through Costa Rica, Ecuador, Colombia, Peru, Argentina. Obviously, we still have GDPR, but Turkey and Saudi Arabia, as well as Botswana have gone live. India's gone live. China, etcetera. It's now becoming a very, very complex landscape for all of our companies, our clients to have to deal with. And for the global organizations that are having to do business in all of these different countries, it means that you can have slightly differing requirements that you have to adhere to in each. Now commonly, we see that most businesses are adopting GDPR as the guiding principle, largely because a lot of these global laws have been based around the principles that GDPR introduced. But we do need to make sure that they are specific and correct. Now, today we're gonna be talking through a couple of key topics. But before we do, we just wanted to start with a quick poll to be able to understand that your personal understanding of compliance within your organization. So that we're just gonna launch that now. And if you could just populate for us your confidence level in compliance with privacy. And we'll just let that run for maybe a few seconds. Okay. Interesting. So we've got a relatively high level of confidence coming through that you're between very confident and somewhat confident to be able to identify what's coming through. So we're going to dig in a little bit to be able to explore what that confidence brings for you or where it comes from, shall we say. So we've pre thought of three sort of myths or common sayings that we hear from our clients that we're going to explore from the different angles that the panellists have their experience from here. And the first of which is to be able to think about your production system itself. And your production system is secure, you thought about your segregation of duties, your fraud prevention, your overall compliance being much broader than just privacy, then you've already gained your compliant view within the industry. It's a fairly common statement that we hear to be able to focus around the production security. But as I think we'll explore a little bit, there are a lot more challenges than only considering production. So Johan, if I can pass to you to start off with, could you explain a little bit for the group here what those impacts are of trying to focus only on production? Sure. Thank you, James. Morning, everyone. So my focus, as James mentioned earlier on, is a bit different. I look after the overall organization as a whole when it looks when we talk about information security and data privacy. And in doing so, the focus is a lot more on the ISO twenty seven thousand and one, twenty seven thousand seven hundred and one, and the SOC two type two standards where we need to align business with these requirements. And what I found is with a lot of the new data privacy legislations and items, specifically the newer ones that are being brought out, they are busy adopting a lot of these ISO and SOC type requirements, forcing businesses to start implementing additional controls and items, taking a bit more of a risk based approach. So saying, what is the actual level of risk that the business is willing to take to work with the type of information that they store on their systems, giving people access to it and how they manage that information. Which makes it very interesting to see how that is actually changing the whole landscape. So we find it's a strong balancing act where we need to weigh up how strictly we go and control all these requirements. So if we look at a production system, there's specific requirements and items that we need to put into place. But you always need to try and mimic your production environment to one of your non production environments to try and keep it up to date as much as possible. So if you do testing on items, you're supposed to do it in a non production environment. And we found with these type of scenarios that more and more people are actually keeping production level information, the same information that they have in the production systems, on their non production environments, bringing in additional risk, additional complexity, and making the risk based a lot bigger. So this in line brings in new considerations and items that you need to take into place. How do you manage that information? If you need to, at the end of the day, destroy the information, what is your complexity and how are you going to identify and find this information? So this is where I think Dani can maybe perhaps weigh in as well because he's more in the field working with this type of information. Yes, Johan. Some of those policies and legislation you're mentioning also impacts us with the data destruction requirements. As you know, there are legislated retention periods for private, personally identifiable information. And we have to make sure when that retention period lapses, that we have procedures in place to get rid of the data, to distract the data. But also something I find we need to sensitize our employees and consultants also, that when they store personal information on their own devices, their own laptop while working with their data, They need to get rid of that data as soon as they no longer need it. So it's not only our production system, but also non production systems and even our own devices that we have to be cognizant of destroying information that we no longer need. Yeah, thank you, Danny. I think it's always an interesting point here, and it's a story that I've told many times when I'm discussing these sort of topics with our clients is when I started my working career, I was working for a call center for an energy company here in the UK. And they had a drive to be able to say that we had to keep call times to the minimum so that we weren't keeping customers on the phone for a very long time doing data entry. So they would actually have everybody working on the call center, a few thousand people, all with little notebooks next to the screens. It's not even always just about the technology, the laptops, the applications, but that we were writing down people's names, dates of birth, banking information, anything that you'd need to be able to actually go and hack their information from the banks. And we were then taking those notebooks, putting them in our bag, and wandering off getting on public transport, anything. And if we happen to mislay one of those notebooks, that could be quite a serious breach under these privacy laws for trying to think about the not just the technical processes, and is it just a production system. It's not even just a system. It's about locking your desktop. It's about making sure that people aren't taking activities like paper management that could also introduce risk to the business. So it's quite far reaching. But then if we come around to think a little bit about our specialist area, Rohan, being the SAP itself and the particular challenges that we see there in a production system, Could you explore a little bit for us where that comes in for both recommended best practices for production, but also then the common sort of business practices for where the real data exists and why it needs to exist there? Yes. So thank you, James. So I think we've touched on a few things. I think when it comes to production, you need to understand your access risk controls. You have to question what access people have and do they have the ability to view full database tables within your SAP production system and do they have the ability to extract data from that production system? And if they're extracting the data, what are they doing? Or what's happening with those copies of data once it leaves that production environment? I think furthermore, and also a reality, an unfortunate reality, a lot of organisations and clients we've met with before, they refresh their non production systems directly from their prod system, which in turn means you have live data within that non production system. And that opens you up to risk. When you think of access control, normally non production systems, whether it be demo systems or quality systems, the level of access is normally a bit more relaxed and now you have live data and that which does, in my books, open you up to risk. And then you have to consider the SAP Data Processing Agreement, specifically Section 2.1.3, that, you know, excludes non production systems from or demo or test systems from that agreement, which prohibits you from actually keeping personal or sensitive data in that non production environment. And then just the final touch point is, do you have support teams that you have working for you that are offshore? And are they accessing national or sovereign data in your whether it be production or non production system that has live data? Because is that not a form of breach because you now that sovereign data is being accessed outside of the country it's supposed to be in? Perfect. Thank you, Variance. I think that one of the common examples again that comes up very simply around those access differences is something as basic as table access. So the transaction SE16 in most SAP systems or sixteen N, SH, depending on which version you're working on. But with that access, it's very, very rare you would see anybody in a productive system that would actually have open access to all data through the tables to be able to link things together. But in a test environment, you need test teams to be able to go and query those tables to find the things that they're then gonna go and test. So there's a very good reason for why you give the access. But if you've copied all of the data and then you've got somebody that's a little bit of a data geek like me and knows all of the tables and fields and has to link them all together, you can very quickly create yourself a little file of data that you wouldn't necessarily want to get exposed. So something as simple as enabling your team to do the testing that you've built the system for actually introduces the risk if you've got the real data. So I think moving away from production then, and we start to think about those production systems. So test systems, sandboxes, training environments, etcetera. There's a number of different reasons we have copies of production systems as their non production environments. So again, before we move into our thoughts around this, we have a brief poll for you to be able to share with us your understanding of what's your approach to protection protecting, sorry, personal data in the non production environment. So do you utilize data scrambling or anonymization? Do you use access and risk controls? Is it manual processes or have you not implemented any protections yet? So again, we'll just leave that there for a few moments to be able to understand what you're doing. Okay. Perfect. So again, another interesting split there with sort of two thirds looking at manual processes that you're trying to adopt and another third looking at the restricted access controls into those environments. Excuse me. So that's very interesting, actually, that nobody is currently using anonymization or you may also hear the legal phrase of pseudonymization as an alternative to anonymization or masking to be able to hide the information, but there was nobody on this webinar that's actually using that approach. So by definition, by not removing the personal data and putting other controls around it, you have a higher risk base. There's no two ways about that. You have controls in place because you have manual processes, you're using access controls, etcetera. But the fact that data exists is already increasing your risk level. So on this one, Dani, I think we're going to start with you to be able to think about where when you're developing the applications and you have to consider non production environments, test environments. What are those sort of key lessons learned that you found? Yes, James. You were speaking about call centers just now. We actually are supporting and developing an application which one of the large telcos use for the call centers. And we see a lot of rigorous approval processes and access procedures for the production system. But nobody thinks about the software engineers developing the software, and often they have access to this live data as well. And there are some highly sensitive data there, which is also so we need to sensitize those software engineers on the legislation and on the sensitivity of the data. In South Africa, we actually had a use case where a criminal code tells and enlisted some of the staff and contractors to obtain this sensitive information. I see many times the customers have a false sense of security because the non production systems are internal, they're not in the DMZ, they're not exposed to the web. And then, especially in this case, also the South African use cases, it is those internal systems that are actually most vulnerable, specifically to staff and contractors with that internal knowledge of the systems. So the extra care needs to be taken on those as well, and they should definitely not be forgotten. Thanks, That's really interesting. And I think, Johan, think if we'd move it across to you before I'll let Rowan get going on this subject because we've got plenty to say on our side. The but in terms of that generalized law and everything else, we're talking about non production systems not falling under the privacy legislations, which simply isn't true. So can you expand a little bit on what that looks like? Yeah, sure. I mean, the main premise is that any of the data privacy legislations doesn't go and differentiate whether it's a development, a QA, or a production environment. It focuses on all information, similarly to your ISO standards. There's a little bit of a focus on saying your production system should be more secure, but it doesn't say that you shouldn't put any controls in place for your non production systems. And I found if you look at some of the bigger incidents that took place within the first half of twenty six. A lot of the controls and items or a lot of the attacks that took place or incidents that happened with major clients' SAP environments wasn't necessarily a sophisticated outside hacker client who gained access their systems due to production environment. But ninety percent of the time related to internal controls, it wasn't effectively deployed to protect information on non production environments. So this led to incorrect access controls or unscoping of information or not giving or limiting contractors or external parties who's supplying services, limiting that access to prevent them from going from one system to another system. So again, all these controls come back to how you actually manage the security controls within the environment to secure it as best as possible. So there's a lot of expectation that your production environment is supposed to be the most secure environment. But by neglecting the other environments, you just open yourself up for bigger risk because of people trying to gain lateral access in between these environments, and then leading to additional compromises or opening you up to potentially actually gaining access to the production environment from that side. And I know this is more on the SAP side, so I'll hand over to you guys where you have more experience in giving users or the visitors today some advice on how to go and securing this environment. Yeah. Thanks, Johan. So I think that there's always, again, a sort of common element that I regularly pick up on, which is pretty much true across most of the global privacy laws. It's not all of them, but most of those new laws that have come through, which is that the person or the legal subject or the data subject, whatever terminology is used, owns the use of their data. And as a business, you have to have informed and explicit consent for each use of the data that you're taking for. So it always We have had clients sort of say to us, it's okay, we're going to go down the consent route. We're going to gather consent. So that would mean that for the manufacturing business, they would need to have consent from every person they've ever sold to within a business. Not just to maintain their data for the purposes of sales history, for processing payments, for actually purchasing goods and moving goods, but also to be able to test those processes. That would have to be written out explicitly. And one of the key things being that informed process, you can't bury that in a contract clause at the bottom of three thousand pages of Ts and Cs within a deal. It has to be explicitly called out and explicitly signed on to. And if you go down that consent route, you then start to get to the increased challenge of what if only ten percent say no. So let's say you've got a million customers or a million vendors or you're a large organization with a million employees and ten percent of them say no. You've now got a hundred thousand data records that you're not allowed to have outside of the productive environment, that they will consent to the use of their data to be payrolled or to be paid or to take payment or to buy, sell, etcetera. But when you do a test data copy, then how do you now remove the records that have not given consent to that process? And how do you keep that up to date? How do you manage it if somebody changes their mind and they've got a whole new process to have to manage around? So that informed and explicit consent is very easily justifiable for production uses of data. But to get consent to use a person's data for training somebody that needs to learn how to run payroll in a test system or a training environment, that's very rarely actually written out into a clause anywhere. So myself and Rohin within the architecture and the delivery teams spend a lot of time on this particular subject. So I'm going to hand over to you there, Rohan, to be able to share a little bit more again, I think specifically around SAP, around some of the challenges that we're seeing on non production privacy management. Yep, thanks, James. I think as Johan already explained the legal side, James, started with the informing and explicit consent focus. Then we look at that from a functional perspective. We've been working with quite a few different companies in different industries. So one like the Ministry of Defense or government bodies, where within those systems they have the sensitive nature of the data that's stored with regards to ammunition stores, where they're located, stock levels of ammunition. Is this any less sensitive if it's in your non production system? And how would that be different to any PII? So the question is, if it's in your non production system, is it less sensitive? And I think the answer is no. And I think we have to look at that from other industries as well. If you look at it from a utilities retailer, a business to consumer customers or clients, every customer in these industries is actually a real person. So for large global or multinational organizations where you have customers across the globe, each of those people are covered by different privacy laws. And, you know, if there's a malicious attack on your non production system and millions of real people's data gets leaked out into the world. Is it okay that it's a test system that got breached? No, I don't. I believe it's not okay. And it won't be okay in the eyes of the people that data has leaked out. Other responsibilities, you know, regarding the DPA Section 2.1.3 and vendor agreements. We're working with an American cookware manufacturer where their main distribution channels are Amazon and Costco. And within that contract, Amazon and Costco, they enforced an agreement of liabilities where real data used for any purposes after billing and delivery or return periods is completed, which is normally sixty days, needs to be removed or destroyed. And when I say for any purposes, that means they're allowed to even test with that data in those systems. I was just couldn't find the mic to unmute there. Thanks, Variance. So, yeah, it is an interesting use case, that one. And it it's companies providing their own liability assurances and legal cover Yes. Through the contractual relationships that they're having with their own customers, vendors, etcetera. So in this case, is an American business that is processing in some of those states that do have privacy laws. But even if they're delivering in ones that don't, because of that legal responsibility back to Amazon and Costco, they can actually be penalized onto those individual contract rather than it being a privacy body enforcing compliance on them. So I think it would be very rare now to find a business or an industry that was totally devoid of wanting to do business somewhere where there was a privacy law that would then enforce. And I always use this as an example that the largest fine that's been provided at the moment was under GDPR specifically, was a one point three billion dollars fine that was leveraged against Meta. But it was leveraged against Meta by Ireland, not by the central body of the European Commission enforcing GDPR throughout Europe, but by the enforcement body of a single country and a relatively small country within the scheme of sort of economies and everything else. But if Meta wanted to continue to do business in Europe in general, they needed to settle this under the confines of a pan European law. So it doesn't really matter where you're based, what you're doing. If you want to do business in those environments, you have to adhere to these laws, and they specifically don't provide statements of nonproduction doesn't count. It's only your productive data that's covered. It is the person's data. Yeah. So it's an interesting challenge. Now if we come to focus a little bit more on SAP itself for the third item that we've we come across quite regularly. Again, we've got another quick poll for people that we're gonna launch around your ability to understand where you're holding personally identifiable information or PII in your SAP system. So do you know the master data places, the transactional places, and the custom places where that data exists to be able to then develop your management processes. So we're gonna We've just launched the poll there. If people could put their thoughts on for how easy you're finding this at the moment. And then what we're going to explore between us is to be able to say around SAP, which is a very valuable ERP appliance, to be able to be fully customized, adapt to industries, go through all of the different processes that are required. What that actually creates now that we've moved into this privacy compliance period is actually a bit of a challenge because quite possibly, you've made customizations to your environment fifteen, twenty years ago that never considered the proliferation of personal data. It was what's the quickest way of meeting the requirement that I've been given? And it meant that people started storing their custom, sorry, their personal data in the custom space. Sometimes when they didn't need to because it was the easier development best practice to be able to pursue that. So unless one, think I'd like to start off by handing over to you, Rohan, to think about SAP itself, that data model, what makes it so challenging for companies and customers to understand where they've got their personal data. Yep. So thanks, James. I think as you mentioned, one of the pain points is customizing SAP because SAP is a customizable solution. That's one of the first things customers and clients do. But to explain this is that within the SAP data model, all data is related. And what do I mean by that is if you take the example of an employee, an employee can have a related vendor record, an employee can be related to a business partner record, and that business partner can also relate, example, to a customer record. And when you start to identify where that PII is, it's spread wide and far across many different tables and locations within your SAP environment. And then you have to consider the customizations where now some PII data might be sitting in Z tables or extended fields within your SAP environment. Then you take it one step further is that you might have all of this data, whether it be an ECC or Sfour system, but you have other integrated SAP systems that have related data. So, now have a business partner or customer record that is a related business partner in a CRM system, and how your data is in different systems, you know, across these different platforms that are integrated. So I think one of the things that I would normally say to understand where your PII is, and it's the important thing, the first step for any client or company is to find and map that PII is your first priority. It's understanding where your data is and where the sensitive data exists. EPI-USE Labs does offer services that can assist with discovering your data. We provide a service called the Data Privacy Workshop and System Analysis, where we use our intellectual property that's been developed over the past twenty five years that scans your system to identify where PII exists based on the data element locations. It also does wildcard searches on data elements to identify where PII can exist. Then we take that output of that discovery and do a collaborative workshop with clients to map out and understand what are their production, their non production requirements. And at the end of it, they also get a full visibility of where all their PII exists. Now, the reason you need to understand where your PII, your personal identifiable information exists in these systems is that when you are looking at those specifics, whether it be anonymizing non production systems or the removal of data in a production system due to retention requirements. You need to know how all that data connects and where that data lies so that when you remove it, you ensure that data is removed in all the necessary places within your SAP landscape. There is one challenge that we do face in this space as well is that there is no specific SAP standards around naming and how you use data elements. So, you know, I think James, this is one of the ones that you've experienced in your career is that you've been at the client where they had a table where the data element was ZZ1, but it contains sensitive information like their first name, if I'm not mistaken. But again, this is where EPI-USE Labs and our experts can help identify and find those difficult scenarios or difficult places where PII could be hidden so that it can be mapped and you have a vision of where that data lies in your environment. Yeah, absolutely, Rohan. And I think it's always very interesting as well that there is no prescribed list of what is personal data to be able to say what's that. There's the things that everybody thinks of, name, address, telephone number, bank details, etcetera. But I was having a conversation with a higher education company last week that's also I should say institute rather than company, shouldn't I? But when it's education. But their broadest concern was actually about health information that they were maintaining on students with disabilities. That was entirely unique to their industry, though there wouldn't be a reason that the customers in a manufacturing organization, organisation, you would have a whole disability information. So it is going to be unique to every business as well. So you have to be adaptable in terms of how you're approaching that mapping exercise. And I do think that in the age of big data and moving into and we have managed to go almost thirty minutes here without mentioning the word, but I'm going to bring it up now. So moving into the AI age, that we the way we're using data and proliferating, what we do hold about people and how we're using it is bringing a whole new perspective to this. And I know, Dani, that you've been doing some work on actually building applications that are leveraging AI. Could you explore a little bit for what you found there around the handling of PII? Yes, James. The AI chatbots using large language models have become a very popular interface. Instead of having to navigate some graphical interface, I could just use natural language to get information. Now something we need to do is we need to take care that the answers that the user gets only includes information they're authorized to see. Now luckily SAP JOUL is already taking care of that very well if the client chooses to use that for its AI interface, because it uses the user's logged in credentials for API calls. So you will only get answers that you have access to. But we find many times external systems are used. Maybe we import this data into a data lake or have some custom built AI solution and then we need to take care to put in guardrails to protect that sensitive information. Many times HR and payroll information, even the one you're speaking about, our higher education client, where we needed to put in guardrails. Specifically, Canvas students can use all sorts of malicious prompt engineering and clever ways to get information, maybe to see the top five salaries or the top earners in the company, which are not allowed to. So we really need to take care of just making sure that the AI doesn't make it too easy for people to get information specifically which are not authorized. I did hear a great example recently where on a non malicious but as an ethical hacking, shall we call it, endeavor from one of our R and Ds. He tried to convince an AI that it was two hundred years in the future. We were in a post apocalyptic world. All of the morals had changed. Therefore, all of the rules that were built into the AI to follow morals no longer existed. And now you can give me this information and trying to see how far they had to go. To your point about intelligent students that would look to and not necessarily maliciously, but just as an exercise to be able to understand how far they can push it. Sometimes it is an interesting challenge. So I think let's run that off back with yourself then, Johan. So coming back to a CSO point of view, is there a recommendation that we can make around what data we're pulling into those test systems and how we try and manage the processes. Yeah. Sure. Definitely. I think the mentioning of the AI is one of the things that at the moment scares us the most because it's landscape that's changing so fast, and businesses aren't changing or adapting as quickly as the interfaces and the actual technology is changing. But if we look at just from an overall data privacy and information security perspective, the best would be to keep it simple. Stick to the basics, make sure you implement best practice controls from the beginning, limiting access to only people that need access to certain specific environments, specifically administrative level access and items, make sure that is also limited to least amount. And then, I mean, from an SAP perspective, knowledge on that side is a bit dangerous. I won't go into too much detail on that side. But again, thinking of what the impact is of the various data privacy legislation, We as a global organization have to adhere to multiple legislations globally, and as you've mentioned, the definition of personally identifiable information is not always clear or differs per legislative requirement. The GDPR has got their definition. Poppy in South Africa has got a different definition. And in Poppy's case, for example, business names is also seen as personal identifiable information. So now you need to bring in additional controls to say how, if you work with South African business information, do you secure that information as well. So focus on the areas that's applicable to your business. Keep it simple. Bring in the basics and make sure that is in place. Then afterwards, once this is in place, you can start looking at additional fancier controls to protect any other malicious active. Perfect. Thanks, Johan. And I think we have had a couple of questions through here that we I think we're only gonna have time to cover one of them, but it actually links to what you were just talking about. So I'm I know I answered the second half of this, but, Johan, I think you just on this a little bit, so we'll explore a bit further. So the example that's given here is that the business is using SAP for finance, but they're using, Salesforce for their CRM system, and they're using Workday as their HR appliance. So part one of the question is, is there any differences between these appliances when it comes to the privacy laws in terms of how they need to be handled? And the second part is then a question that I think I'll probably take myself to say, when the data is shared between those systems where it's integrated, how does that work with scrambling if we were to take that approach? So I think, Johan, if you could explore a little bit first, is there any application specific view that needs to be considered here, or is it more general? So each well, each application has their specific controls and items that can be implemented. But from a general perspective, you need to understand how they integrate, how they are connected, and follow that same principle of least amount of access throughout each of these different environments. They all work with personal identifiable information. They all are interconnected, and they all kind of share the same public information. So you need to understand how that sharing is facilitated between each of Is there encryption in transit in place? Where is that information being stored? So do you have encryption in place on that side? And who's got access to that information on the storage side as well? So as a general, there is baseline best practices that must be followed to secure that information. But as I said, each application has their own nuances with regards to how you implement your single sign on multifactor authentication and all sorts of other technical controls to further protect Perfect. Thanks. And yeah, I think that there's a heavy functional angle to this as well because the refresh policies of these appliances are very different. So the workday, for example, has a weekly refresh that is enforced on sandbox environments that will always take productive data back down. It can be delayed for a couple of weeks, but it will eventually always catch up and have far more regular refreshes than your SAP system. So if you are to take anonymization as the approach, you need to make sure that you've got solutioning that actually considers that to be able to say, how do I maintain that referential integrity of the data flow within those non production systems when they're all being refreshed at different times using different technologies and linking together? EPI-USE Labs are specifically building out appliances to be able to do that. We're working with a couple of ramp up clients at the moment on Concur or Rebo. We've been dealing with SuccessFactors for quite some time. Salesforce and Workday should be going live shortly within the next couple of months. So we're looking to act as that middleware, the interface between all of the different appliances to be data specialists. We're not going to be able to provide you everything that Johan does for us as a business to be able to come and act as your CISO. We're not looking at all of your business process, your IT management, your system management, your encryption. But we can focus on the data and the linkages and the understanding of how they link together. So I'm going to close this out. I'm aware that we've gone over by a minute or so there for the planned time. So I'd just like to thank everybody for joining us today. We hope that it's been an interesting session, and you've gained some practical insights for SAP and data privacy. As a reminder, the session has been recorded and it will be shared with you afterwards. And if there are any further questions, please feel free to reach out. We'll absolutely respond to, to all questions that we get back in conversations. So thanks for being a part of today's discussion, and we hope to see you in a future, event.