Could your SAP non-production systems be your biggest compliance blind spot?

Welcome everyone to today's webinar. Could your SAP non production system be your biggest compliance blind spot? I think security is still very much one of the top priorities for IT professionals, SAP professionals. And today, we're gonna focus specifically on non production systems. I think everyone is really focusing on keeping their production data safe, and sometimes we don't realize that there might be some blind spots also in our nonproduction systems. So today we have with us, we have Rohin Ramji. Rohin is one of our security experts here at EPI-USE Labs with loads of experience in different modules within the SAP environment, so HCM, at the beginning and then moved on to more focusing on privacy. So yeah. A brief introduction about us, about EPI-USE Labs, just in case you don't know us. We are obviously a business. We have software, we have security, we have services, and we focus specifically on SAP. We have more than one thousand nine hundred clients worldwide and we operate in different fifty countries. Just a few housekeeping items for everyone that's connecting. I see already some questions about it. This session will be recorded, and we will share it with you afterwards. The lines will be muted, but you can access the chat box on the screen and send any questions. So if we have time, we will ask the questions to Rohin at the end of the webinar. If not, we will make sure that you get your answer via email after the webinar. Quickly, the agenda for today. Rohin, if we can skip slide. Yep. I moved on. Okay. It takes a while. Alright. So we are going to have a quick look about at the growing of GDPR costs and what does it entail for businesses, the core principles of GDPR, then we're gonna have a look at the SAP DPA, what does it say, what are they expecting from us or from you to do about your non production systems. We're gonna talk about the blind spots, and then we're gonna move on onto Data Secure and how we can help you with a brief demo. And then we're gonna show you what options you have in term if you wanna take a step now, there are different options whether you can do a DSMR or actually engage with us for a full privacy workshop. And as I mentioned before, if we have time, we're gonna have to do a brief q and a. So without further ado, I will hand over to Rohin. I hope you enjoyed the webinar. And, yeah, Rohin, over to you. Thank you, Maria. Welcome, everyone, to the webinar. As Maria mentioned, my name is Ryan Ramji. I've been with the EPI-USE Group for eighteen years, and I moved over to Labs five years ago. And I specialized in security, privacy, and risk. So today, we're gonna look at, you know, the growing costs of a GDPR reach. We are at a time and age where data held in within your company's SAP system is actually an asset. We see this with the number of personal data breach notifications recorded at about four hundred plus per day in the European Union. This is on average, increasing by twenty two percent per year. There's numerous headlines of cyber attacks causing operational downtimes for organizations, millions of customer data leaked due to overlooked vulnerabilities within systems. Data breaches also have an impact from a financial perspective. On average, GDPR breaches can cost up to three point three million per data breach, and that cost is either operational downtime or it is in the form of a GDPR fine that's issued to a company due to a breach. Now one of the major impacts that a data breach has on a company is that you it's always one hundred percent guaranteed that a company will suffer reputational damage on a data breach. And it's this loss of trust towards stakeholders, employees, customers, vendors that really impact companies. And some companies cannot recover from these rapid from the reputational damage of data breach. That being said, this is that's a call to action for companies to ensure that they are not a statistic in the world of data espionage. The other item that comes into play is the higher operational risks for companies. Additional vetting, who are you letting into your system, increased vulnerabilities due to insider threats within your systems, due to the value of the data has in the market today, you know, people might be within your organization for the sole purpose of getting that data out. And it's something that needs to be looked at. I think we touched on it. A single breach involving an employee, customer, or vendor data in the test environment can trigger regulatory action with lasting reputational damage. Now to touch on some of the core GDPR principles, there's five fine fundamental principles that guide compliance in a non prod in non production environments. The first is purpose limitation. So purpose limitation is that personal data of employees, customers, or vendors cannot be repurposed for testing without valid legal basis or consent from these parties to use their data for testing purposes. The other is data minimization. As a company, you should have only the minimum necessary personal data that should be used for specific testing objectives within your system. So you only have the data there for the specific re for a specific reason and not for everything. The next item is integrity and confidentiality. So even in your nonproduction systems, you still need robust security measures, whether it be from a the form of authorizations, your standard company VPN and policies, but you need to have the correct measures into reduce or, you know, to protect that system with reduced controls in the test environment. Next item is storage limitation. The from a GDPR perspective, once your test data or once the testing has been done with a specific set of data, it should be deleted for that. It should be deleted from that system and not continue to exist within that system. And then finally, accountability. As an organization, you must ensure that you show or demonstrate adherence to the GDPR principles in your nonproduction systems. I'm gonna mention this a few times in today's session. There is no differentiation between a production or nonproduction system in the eyes of the GDPR policies. Now when we talk about these, these are from a legislative perspective and GDPR principles. Now how does that impact you as a company? I'm not too sure if everyone on the call is aware, but this SAP Data Processing Agreement in section two point one point three, it clearly states in the data processing agreement where SAP or subprocessors makes available nonproduction environments, whether it be a dev quality system. A customer shall not store personal data in such environments because nonproduction systems are not intended for processing or storage of any personal data. And because of this, it is technique technically excluded from the scope of your SAP data processing agreement. What does this mean for you? It means as a company or an organization, you need to ensure that you have the necessary safeguards in place to ensure that you do not store or have live personal identifiable information in your nonproduction systems. Now this is what leads to the main topic of today's webinar is that there's many blind spots when it comes to your nonproduction system. And the main blind spot is that you have production level data without production level governance. Now I know many customer I know many clients that we've engaged with in the past and still ongoing that currently have live PII data in a nonproduction system. What happens in these in instances that you have your functional teams and your teams that are trying to improve your production systems, and they need real test data to make sure that any developments upgrades that they are working on is tested on the best data possible. And what it then leads to is companies or clients will do a nonproduction refresh from a production environment with live data. Now that increases your risk because, in general, in your nonproduction system, you have lower or weaker governance over identical data that you have in your production environment. Now what does how does this happen is that generally in your nonproduction systems, you have broader access. You have the situation where you have consultants, system your system integrators that have access to your nonproduction system to support you with high level access so that they have the so they have the ability to troubleshoot problems within your system. The danger is that when these individuals have this high levels of access in a nonproduction system containing live unmasked PII data, you create a large security loophole, and a simple security lapse or accidental exposure can lead to that significant privacy breach. And most of the times, privacy breaches are due to that lapse in judgment or an accident of data that was taken out of a system. I mean, how many times have you got have you been in your system with access to table access like s c sixteen n, etcetera, and then a dump of a table and stored it on the on your computer desktop? There's no there a lot of times, there's no control of over those actions and what happens to those files once it leaves your SAP environment. Now I think I mentioned it as well. Your nonproduction systems need there is no differentiation in GDPR when it comes to whether it's a production or nonproduction system. It's it there's no difference. So, therefore, you need to comply because if a regulator investigates your landscape and identifies that there is real data in your nonpro or live data in your nonproduction systems, the potential find that you could be facing is the same that you would if it was a live system. And you have to then consider that in your non production systems, have limited logging and review. You have those frequent system refreshes bringing the latest data into that system and live data. And you also have limited audit visibility. So it is a blind spot that a lot of customers forget or it's overlooked because the demand to improve or make sure your production system is running smoothly so business can continue as usual. Nonproduction systems generally get overlooked in this instance. Another item that will raise the issue for where it is a blind spot. A lot of customers or clients are currently on this roadmap or migration part to migrate to cloud or s four HANA. And as part of these migration processes, you're in the position where additional systems have been stood up and created, additional development test systems that are stood up to do your migration work or do the migration process if it's a brownfield conversion on your current information. And normally, these systems are refreshed from a production environment so that you can test that execution within those environments. And what this does is it means that your the data you have now has increased because the number of systems holding the data has now significantly increased. You have live data and additional systems, so you increase your exposure. And the items that you have to ask yourself is who is doing the work. Now a lot of times during these projects or migrations, you have your system integrator or your third party consultant. But where are the where is this where are these consultants or system integrators accessing your data from? You are currently positioned in the European Union or within the UK and you have to follow the GDPR laws, and you now have a nonproduction system, whether it be a dev or polity that a migration process is being executed on, and you might have consultants that are sitting outside of the European Union working on this migration, and they are exposed to your live PII data. And in that aspect, your data sovereignty laws are now in breach. Do you have all your necessary security policies still active in those systems that have been stood up for the migration purposes? And this is something that you have to consider. We're currently in the process of helping a government agency who reached out to us where their requirement was that they are currently in the process of migrating to s four sovereign cloud. And before they could hand over their staging system to the incumbent to do the migration pro the brownfield migration process, one of their internal processes was that all data needs to be anonymized before it's handed over for the conversion to take place. And this is a step that a lot of clients and customers have overlooked, some that have already gone through the process of migrating to the cloud or doing a s four private cloud conversion. But there's a lot of customers that need to consider this if they're on that road map of going to do a cloud migration. Okay. So gonna take a bit of a pause at the moment, and I am we are going to put up a poll for the audience. We'll give everyone a few seconds of ten to twenty seconds to answer the poll. The poll question that's gonna go up right now is why what where does your nonproduction SAP data security sit on your road map? So is it within the next three months, the next six months, twelve months, two years, or are you still evaluating your options? Just gonna give a few more seconds. I can see people are answering the poll. Thank you. K. Okay. I will then I see a even split where a lot of people need something or they need to take action within the next three months, and quite a few are still evaluating what options there is for them. It's a interesting split, and we are here to help. So thank you for taking the time to answer that poll. So now that we've spoken about, you know, from a the core GDPR principles, what the DPA is, and what some of those blind spots are, the next thing I'm gonna talk about is some of the common approaches to nonproduction data privacy that are proposed or implemented. So these are four of the most common ones that are put forward. The first one is synthetic data. Synthetic data does give you high privacy, but what synthetic data does is it lacks data relationships, and it doesn't always reflect scenarios or edge cases that you could possibly have within your production environment. From a GDPR perspective, it's great, but it doesn't normally help your functional teams that need quality data for testing purposes. The next item that could possibly be looked into is production levels, controls, non production. So restricting access via authorizations and roles without transforming your data. What this means is that you have the same level of authorizations and controls that you would have in a production system in your non production system. But the impact that has is it generally slows testing and limits usability. It creates also operational bottlenecks. So when cert when your system integrator or parking needs necessary access in the modern production system to troubleshoot, generally, that means they're requesting firefighter or requesting additional access for a period of time so they can do their job. And that process of requesting these actions add to the time to resolve issues within the system, thus creating bottlenecks in your support and nonproduction environments. The third item is manual scripting. Manual scripting can is custom scripts that apply data to your date your tables within your SAP system. Manual scripting is difficult to maintain. Even in the age of AI, which could simplify manual scripting, the problem that happens with this is it's not guaranteed, and it could miss custom tables or and dependencies within the SAP data model, which could lead to not con no. You would not have consistent test data. You might still not have those unique production scenarios that you need to test on in your non production environments. So it's not necessarily the easiest option. It also takes a lot of manpower and time to ensure you get that data into the system. And then the final one is ad hoc or partial masking. This brings in the thing. Anything ad hoc or partial masking can lead to inconsistencies in your systems or across your systems during refresh cycles, and it then also lead to breaks in your referential integrity, which makes testing and the chances of errors or short dumps occurring in your nonproduction system much higher. I think a light a slight segue, and this is where EPI-USE Labs can come into assist, is that with EPI-USE Labs, we have what we call Data Sync Manager suite. The Data Sync Manager suite is made up of five products. The Data Sync Manager suite has been developed for the past or over twenty five years. The Data Sync Manager suite is made up of Shell Sync, which allows you to build new system shells quickly, Client Sync, which allows high performance client copying and time slicing of data that gets imported into your nonproduction systems. Object Sync allows you to get test data on demand so you can copy data from a source to target. We have Object Extractor, which allows you to x do data extracts from a SAP system. And then finally, what we are going to talk about today in more detail is Data Secure. Now Data Secure is our comprehensive data protect protection solution that allows the anonymization of the PII data in your nonproduction system. We've been as I said, we've been developing DSM over the past twenty five years. And what we've developed over the past twenty five years is we have gone out and we've mapped a lot of the SAP data model. A lot of you on this call already know this, but in an SAP system, all data is connected. And without understanding that data model, to understand how to anonymize the data is impossible. An example of that is we've had clients that created custom programs to do their anonymization of their data, but they didn't have a understanding of the SAP data model, which then left a lot of PII still exposed in their nonproduction environment. Now when I say all data is connected, a simple example is that you can have an employee record that has a related business partner record. They can have a relate that can be a vendor have a related vendor record. An employee can also have a customer record. Now when anonymizing data, if you only anonymize the employee data, you then leave the business part of the data not anonymized or it's anonymized not consistently. And that's what gives our solution the power is that we've mapped that SAP data model. It gives our solution the ability to consistently scramble data between multiple SAP environments as well as non SAP platforms. Our solution is delivered with out the box comment content, mapping common PII locations within the standard SAP delivered policy, and it can be launched with minimal implementation efforts. So what we do offer is we offer what we call our essentials package. The essentials package is based on standard SAP the standard SAP data model, and it covers common PII locations that we've identified in the part in the many years of implementing Data Secure customers. Our essentials policy is easy, quick implementation, and it can be a starting point for many customers on their nonproduction privacy journey. And the beauty of our product is that ours, the solution is expandable and customizable. So some clients start off with an essentials policy and they invest at the later stage to add customizations into it. As I mentioned, our solution is modifiable to include additional configuration. I know a lot of people or customers have custom tables, fields, Z tables, that could possibly contain PII and need to be also considered when doing anonymization of data in your system. Data Secure has the ability to anonymize your entire SAP client for testing purpose testing or training purposes. You can have multiple policies to differentiate the data, how data is scrambled, whether it'd be in dev preprof, if you have different rule sets. A beauty of the solution, it is provided to you as a transport, and it is in our SAP approved namespace slash USE. Therefore, Data Secure does not need any external connections or middleware. So your data never leaves your SAP s eight. It can be used independently, or it can be combined with a DSM data copy, or it can be combined with Client Sync. I'm gonna just start. This is a prerecorded demo that I'm gonna walk through with you, but this is just to highlight how Data Secure works. It's a very quick high level demo. On the right hand side, as you can see, I'm searching for an employee in the non production system. As you can see, the employee is Sam Jones. I'm just gonna open up the info type to personal data and just to show the data. As you can see, it's Sam Chris Jones, Social Security number one two dash eight nine seven five one two. I'm now gonna go over to SuccessFactors as Data Secure has the ability to scramble data in SuccessFactors. I'm searching for the same employee, the related record. As you can see, Sam Jones, and I'll x I'll view the Social Security number. As you can see, it's one two eight nine seven five one two. I'm now coming over to my SAP easy access menu where I'll be putting in the data secure transaction code forward slash n forward slash u s e forward slash d s. This will take me to the data secure landing page where I'm going to select the mask objects option. Please note, mask objects allows you to mask a single object or multiple ob or at a time where the mask client's option allows you to do mask an entire client based on your policy. As you can see, there's a selection option screen where I'm selecting the personnel number. And on the left hand side, I have the integration three where I have all related integrations selected. What does that mean is that when I do a selection preview, any related objects that link to that employee is considered in the execution of masking. I'm now gonna be selecting a masking policy from my drop down. Once I've selected the masking policy, I'm going to the execution option. I will be giving this execution run a description, webinar demo. As you can see, there's execution options. We can do parallel processing. Mans can be scheduled, and we can set up notifications. There is also a test mode which goes through the full process without updating the data. So once I've clicked execute, it brings me to the Monitor Desk. The Monitor Desk is the central hub that allows you to monitor any execution runs that have been done. I'm clicking refresh, and the webinar demo execution run has started. I'm gonna double click into the Monitor Desk run, and this is just a overview where it also show how many keys have been identified. And as I refresh, once the keys have been calculated or the values are calculated, it will then start the update process. So it's not currently moving on to start the update process. Once the update process starts, it goes through making sure that the data is anonymized, the data is aligned between the different business objects, and it starts the update process. It is updating the data on the on premise ECP or ECC or s four system. At the same time, it is sending a old data up cert to SuccessFactors with the anonymous data. As you can see, the run was completed. I refresh the master data screen, and as you can see, employee one triple zero nine six has now become Maybell Mundy, and her Social Security number is six three two one two three zero four seven. Similarly, I refresh the SuccessFactors screen, and as you can see, the data has been anonymized successfully in SuccessFactors as well, and it's consistent between the two systems. Now this is just a very high level demo of the solution. If you are interested or want more information, please reach out to us, and we will do a more in-depth demo going into a much more of the solution. And then the final thing is the first step to assessing your SAP Data Privacy Risk. So one of the first steps as a company that you need to take is you need to understand where your PII exists in your system. So with EPI-USE Labs, we have two offerings that can start your journey. We offer what we call our free DSMR assessment. Our DSMR assessment is a transport that we provide to you. And with execution steps, you apply the transport, which is in our USE namespace to your SAP instance, ideally a production or nonproduction system that has been re recently refreshed. Our DSMR does not once you execute the DSMR, it does a metadata extract, which we ask you to load to our client's central portal. Please note our DSMR does not take any PII out of your day out of your system. It only takes metadata, but you can scrutinize the output of the DSMR before loading it to the client central portal. From this, we do have a high level output of the PII identification in your system. We'll do a we will do a short thirty minute playback session to show you the findings from the three d SMR, and then it will also give you a view of a partial view of where your field analysis and your PII locations within that system starts exists. Then the other option we do offer is a data privacy workshop and system analysis. This is a paid service engagement where we do a we do an in-depth analysis of your SAP environment. We also come we hold a one day workshop where we invite your data privacy officer functional teams to participate because what we wanna do is we want to identify what your requirements are, but also find that middle ground. I think I've said this to many clients before, and I'm gonna say it again. We always have this power wall. Your data privacy officer is gonna want everything anonymized, masked, and then you have your functional person which wants the most realistic production copy or closest to production data to give them proper functional testing. And what we do in this workshop with our expertise, we facilitate this to find a happy middle ground between your data privacy officer functional team. In this session, we also then discuss production privacy requirements, your non production privacy requirements. We are we'll map out and discuss your retention process flows. We will also map out your SAP object definitions and integrations of data. If you have multiple SAP systems in your s a estate, whether it be a s four, CRM, SRM, we then also map out and discuss your cross system integrations and system alignment. And finally, we also provide you a detailed table and field analysis of where all your where your PII locations within your system exists. If you are interested in any of these, we do have QR codes on the screen. This presentation will be shared as well that you can book a free DSMR, or if you wanna take the dive into book the data privacy workshop, there's a QR code for you as well. That concludes my presentation for today. I have run over time, and I think we would any questions would probably be we will come back to you with those answers on email. And I will now hand over to Hind. Thank you, Rohin, for this insightful session and for sharing your expertise with us. Also, thank you to everyone who joined us today. We hope you found this session valuable and came away with the useful insights. As Rohin said, unfortunately, we're out of time for questions today. But if you submitted one, we'll make sure to reach out to you via email. Also, if you have any other questions that come in mind, please feel free to reach out by email as well. Just before we wrap up, we would really appreciate your feedback. A short survey will pop up in your browser as soon as the webinar ends, and it would be great if you could take a minute to complete it as your feedback will help us improve our future webinars. Also, please keep an eye for our next webinar where we will be talking about mastering SAP data with the strategic decommissioning. So thank you again for your time today, and have a great rest of your day. Thank you, everyone. Thank you.