SAP 데이터 프라이버시 진단에 관한 10가지 질문

Thank you for joining us today. As many of you are starting your twenty six planning, data privacy and risk inside SAP are becoming increasingly difficult to ignore, especially with rising audit requirements, regulatory pressure, and growing data volumes. Today, we'll unpack the ten most common questions we receive about our SAP data privacy assessment, what it involves, what you gain from it, and how organizations use it to understand risk, prove compliance, and build a strong internal business case. To help answer these questions, we're joined by Rohin Ramji, who leads EPI-USE Labs to start a privacy offerings across both production and nonproduction SAP landscapes. Rohin brings deep expertise in data privacy, security, risk, and SAP HCM. Before we dive into the questions, we'd love to get a quick sense of where you are today. Please take a moment to answer our three short polls. So poll number one, what is your biggest SAP data privacy challenges right now? K. Great. I think let's move over to the next poll. So for the second poll, are you planning on investing in any data privacy initiatives in twenty six? Okay. Great. So I see we're considering it as an option selected, and then we can move over to the third poll. Are you aware of SAP's updated data processing agreements specifically around live data in nonproduction? Okay. That's good to know. Rohin will cover this topic a bit more today. Oh, and we have also a few selected yes. Thank you for your response. That gives us great context for today's questions. Now let's move into our ten key questions for Rohin. So, Rohin, the first question, why do I need to worry about data privacy? So the reason companies need to worry about data privacy can be driven by a number of reasons. So with the introduction of privacy laws, like the protection of person personal information act, GDPR, PDPL, etcetera, around the world, It puts the responsibility on clients to ensure that they have the correct measures in place to protect their personal identifiable information. If you do not take those necessary measures, you do risk the possibility of being noncompliant, and noncompliant noncompliance has consequences. Example of some noncompliance in Europe, as an example with GDPR, you can get a twin up to a twenty million euro fine or four percent of a company's global turnover. The one the other thing that companies do not consider is that you there is hundred percent reputational damage if you have a data breach and live data has leaked out into the world. The other thing to consider is high operational risks as you have increased vulnerabilities to insider threats and security breaches. I think something that clients need to understand, sometimes a data breach is not a malicious data breach. Non production systems have the is normally less secured and has the authorizations are not as precise as your production authorizations. And you also and normally that access is given to a wider audience, and they have a larger degree of access to data in those non production systems. What this leads to is you get yourself into a scenario where you have a employee that might do a data dump of a table, and that table gets shared. But while sharing it via an email as an example, that email could be sent to an incorrect participant as an example, and the data's out there, there's no way of getting that data back. The other item is nonproduction systems normally also have external contractors or external parties that have access to that system, and therefore, you shouldn't be keeping live data in those systems. And that will lead into the other thing, the SAP Data Processing Agreement, referring to section two point one, two point one point two, and two point one point three, where clients make available nonproduction environment of SAP services. Customers should not store personal data or live production data that consists of personal data in such environments. Nonproduction environments are not intended for processing and storage of personal data and are excluded from scope of the SAP DPA. Therefore, if there's a breach of a nonproduction system that has personal data, the liability sits completely with the customer slash client, and the customer is in breach of their data processing agreement with SAP. And it's something that you should be aware of, going forward. Great. Thank you so much, Rin. Now we can move over to the second question. What does the SAP data privacy assessment process involve? We have two approaches to the data privacy assessment. So we have the free data privacy and security assessment, and we do have a paid engagement. Both these would require transport that is applied into your SAP environment. Ideally, this transport gets applied all the way to a production system or a recent copy of production. In the terms of the free data privacy and security s assessment, it will be up to the client to execute the program. And once the program completes, the results can be submitted to our client's central portal. Please note, our free assessment does not remove any PII from your system or expose any PII from your system. It purely reads metadata, and the output file can be scrutineered by the client before it is shared on Client Central. And in regards of the paid assessment, it again, as mentioned, it's a transport that would need to be applied to that environment, ideally production or not a recent copy of a production system. And that assessment then will be followed it will be executed by a consultant. It's also followed by a further analysis. Once that analysis is complete, there would be a workshop that's carried out. Great. So over to our third question. How does the free data privacy and security assessment assist before committing to the paid data privacy assessment? This is quite a simple answer. The free data privacy and security assessment, when that executes, it does checks on sample dataset sizes within your environment. But through those sample data checks, we can confirm a scale of issue to give you an understanding of what level of personal identifiable information you have in your system without any financial investment. Then over to the fourth question. During data discovery, what exactly do you analyze in the SAP data dictionary, and why is this step so important for identifying personally identifiable information? The data discovery software leverages our unique intellectual property that we've been developing for the past twenty five years, which contains defined mapping of SAP data throughout the throughout SAP in finding the personal identifiable information. We scan the data dictionary via the data element, which also does a wildcard search to identify tables and custom tables that could possibly contain PII, as well as check the contents of these tables. The reason this is important is that within SAP, all data is connected, and PII can be spread far and wide across many tables within your SAP system. It's critical to identify all these locations to ensure when privacy processes are put in place in the case of non production scrambling or in those production data erasure situation that all the necessary data is scrambled or removed when executing those processes. Great. Thank you. On to the next question. What types of deliverables can clients expect at each stage of the assessment, both the high level overview and the comprehensive assessment? For the free data privacy security assessment, once the client, applies the transports and executes the report and shares the results to our client's central portal, we will review the output of that, and then we can host a meeting with the client to highlight the findings from the free data privacy and security assessment. For the paid data privacy and security assessment, the following deliverables can be expected. A consultant will come in, execute the data discovery program, which will be followed by a in-depth analysis of what's in the client's system and what's based on the output of the discovery. Once that analysis is completed, we then prepare and have a workshop that will be managed by our consultant. And out of that workshop, we have a detailed data privacy workshop and system analysis report that gets shared back to the client. Okay. So what does the detailed SAP data privacy and risk assessment report include, and how is it used by clients after the engagement? After analysis, you'll be presented with a detailed report which outlines the following. It will look at your production privacy requirements from a retention perspective of how long you're keeping your data and what you want your retention process flows are, as well as the mapping of the PII data and production and how if a ratio of data takes place, what data gets removed and how it gets processed to be removed. Then we also do the same within non production where we look at all the non production privacy requirements in this essence, where we have personal identifiable information in your production system. And if we are masking that data or scrambling that data, what type of scrambling processes will be executed on that data. We also do object definitions and integrations of data. So within the output, we document all the SAP objects and the integrations between the data. We also do any cross system integrations and data alignments. In the instance, you have a ECC or a Sfour system that's connected to a CRM or SRM system. We identify any of those integrations and process them requirements that the client might have within the document. And then finally, we have a detailed table and field analysis showing exactly where personal identifiable information lies within your SAP environment. This assessment can be used as the scope of a data privacy implementation. It can also be used to show auditors that there's understanding within your organization of where of what data privacy requirements you have and the necessary steps that you're gonna take forward to make your system compliant. Great. Thanks, Rohin. So the next question is, what is the typical timeline for completing an assessment, and how are the five days of work structured across the two week period? The assessment is five days FTE and is normally carried out over one to two week period. The assessment is broken into three pieces. There's a three days of system analysis, which the consultant coming in, executing the data discovery report, taking the output, doing a further analysis with the report and your system, and preparing for a workshop. Then we have a one day workshop. We will then require from a client perspective, the client DPO, test leads, and data owners to be present. And then we go through we workshop our findings with those representatives to map out what the what are the requirements within those systems. And then once that's completed, we have one day to finalize the documentation and the assessment report. So we take our findings plus the output of the workshop, and we compile the final assessment report. We'll move over to the next question. How do the managed workshops with functional, technical, and compliance teams add value, and what should organizations prepare for before attending them? The value add that we get of having those teams within the workshop is that we get clear requirements for the production and nonproduction data handling. It is also beneficial to align the expectations between the relevant parties within the organization. And what I mean by that is that, you know, we normally come into these situations or workshop situations where you can have your data privacy officer and their main goal is data compliance. And they either wanna scramble all data or remove all data from these systems, but they don't actually have the functional understanding of a SAP system and what impacts by scrambling all the data or removing all data in a production system can possibly do to your system. And then we have the functional team. The functional teams that would want the best quality data in their non production systems for comprehensive testing of processes. And if they could have it their way, they wouldn't want anything scrambled or any data removed from production to keep the integrity of their data. And it's about having these parties within the session and finding a balance between them so that we can show a balance between data privacy and function a functional system that can still allow for accurate testing from a functional perspective in nonproduction as well as having a production system that meets DPO requirements with regards to g GDPR compliance with full data integrity. For clients or for these teams when attending the workshop and preparation that can be done, I think what we would normally say is if you all have made any steps within identifying retention or any data privacy steps that you have previously taken with regards to what data you would like to scramble or how you'd wanna scramble it or how you'd wanna manage that data, If you can bring that information into the workshop, that is a great preparation step. The other thing is if there's nothing or you don't have any of that available, it's about just being present in the workshop and making your thoughts heard and being part of that discussion so that we get clear and balanced requirement documented. Great. Thanks, Rohin. For companies operating in highly regulated industries, how does the assessment support compliance with global privacy legislation like Poppy, GDPR, PDPL, and others? We have completed this process as at many clients around the world. And within those clients, we've also done this for government bodies. Example, the tax offices, ministry of defense, as well as the pharma industry, as well as utility industries with validated systems. And in all these cases, a detailed plan of data management is required. This discovery process is not only compliant and valuable in these industries, but for EPI-USE Labs, it is a mandatory step that we would need to take. So what are some of the most common privacy gaps or risks uncovered during assessments, and how do organizations typically address them afterward? After doing our data discovery process, a lot of clients the gaps that are identified within client systems is that they have no formal process on scrambling or masking data within their non production systems. Or we also identify gaps in clients that have taken a step for data privacy and they created their own programs that does the scrambling or masking of data in their systems. But the gap that we found is that they don't always have that background of knowing exactly where all their PII is. So when those programs are created, yes, it does mask data, but what we've uncovered is that there's a lot of other tables within the system that contain live data. So that's one of the gaps that we identify. So the others, PII locations and systems that shouldn't contain PII. A lot of clients, you know, SAP systems grow so fast. And now if you're running SAP for ten, fifteen, twenty years, your dataset can grow really large, and there's many different changes, upgrades that people add to their systems, and new tables get created, and data gets spread quite quickly within these environments. So a lot of times, we identify locations that shouldn't contain PII, and it's a surprise to the client that, oh, those tables shouldn't have had that data. The other thing is a lot of clients, they have no production process in place. They don't have their retention requirements documented. They don't have retention process processes documented, and it's it's a gap that we need to fill and help them develop those processes so that there's a for their retention requirements so they can start working towards, you know, being more compliant. A gap that a lot of clients says is that they're unable to respond to a data request or data erasure request. So if a customer or employee pick up the phone and ask what data you have or meet clients, don't have the necessary means to provide that information in a timely manner. They can, but it takes very long because they manually go try and identify what data they have of this customer or employee. And then once that employee reviews that data, if they do the if they request for their data to be raised, they don't have the necessary process in place to do that erasure request. What organizations typically do to address these afterwards is once the data discovery is completed, they normally do work with us as we do have a data privacy suite that covers these gaps. We have software that allows us to mask or scramble nonproduction systems, which is called Data Secure. We also have software available within for production requirements with regards to data requests, which is our data disclose software. We also have software to deal with the removal of the data when the data is requested to be removed. We have software that allows us to do that, which is data redact. And then we also have the ability to take those retention requirements and have a program called software called data retain, which then proactively identifies data that meets those retention requirements to be removed. Right. Thank you so much, Rohin. That wraps up our prepared questions. We'll now open the floor. Please share any questions in the chat, and Rohin will address them. So, Rohin, how do you identify and classify sensitive data in a highly customized SAP environment without disrupting business processes? That's a good question. So our data discovery software, whether it be the free assessment or the paid engagement, our software does as we mentioned, it does a date data dictionary search based on the data element over the our twenty five years of building our products and us being one of you know, developing our privacy software, we've identified what data elements could possibly hold PII. As part of that process, we then scan the database looking for the table the tables that have those data elements. And we do, as I mentioned earlier, is a wildcard search on those data elements to identify it in custom tables and fields as well. It is not disruptive to business as it is a the program runs on a single process in the background. It is not resource intensive, so it will not impact a client's production system when executing. If a client does have any concerns around that, the execution can take place over a weekend or in a time when there's less activity on client systems. But as mentioned, we then scan the date we scan the entire database, searching the data elements, doing wildcard searches as well that will identify the possible locations for PII within the SAP landscape. Okay. Here's another question. How invasive is the assessment process, both the complementary assessment and the comprehensive assessment? Will this require heavy resource involvement from clients? No. So from a programmatic perspective, our free assessment and the data discovery program that we apply into your system is not invasive with regards to the actual system resources as mentioned. It is used utilizing a single background process. It runs in the background without actually impacting system performance. From a perspective of client involvement, obviously, we would require that the basis team or someone from the client perspective to apply the transports to the necessary systems. So that is one of the requirements that would have to that we would need their support in doing. And then, obviously, from a paid assessment perspective, when we get to the point of doing the workshop, we would need, attendance from, as I mentioned, the data privacy officer, functional, experts, data experts with that will be present in the one day workshop. Okay. I see we have another question. Once we receive the assessment results, what are the typical next steps for remediation, and how long do they usually take? If we are doing the free assessment, once the free assessment is complete and we review the results, we as I mentioned, we will host a meeting with the client and walk them through the results and what we've identified with the free assessment. Normally, with regards to that, the free assessment, the next step is do they want to actually financially commit to maybe doing the full in-depth discovery and workshop? And that's possibly the next step to move forward. With regards to the paid assessment, once the assessment report is shared and, these items identified, what we will normally do is we will go through and obviously put together, we will use the output of that assessment report as a scoping document, and then we would obviously put forward dependent on what the client is looking for, whether it's non production or production privacy, we can then obviously move forward and price accordingly some of our solutions. With regards to if it is a authorization or access request, we have a GRC and authorization team that we can work with our clients as well for to help them mitigate any authorization issues. Normal turnaround is dependent on what the client requirements and how customized the solution is. If it's a simple implementation, as I said, we offer our products in different tiers. With non production scrambling, we do have a essentials package that covers just essentials, but it doesn't cover all customizations. Based on the output of the workshop, if a essentials package will work for a customer, that is normally a quick turnaround time to implement, or it is at the end of the day, it is dependent on the number of customizations. But we can remediate these problems between within a span of two weeks to three months dependent on the scope of the implementation. Great. Thanks, Rohin. I see we have another question in the chat. Can this assessment help us prepare for multiple global privacy regulations at the same time, like Poppy, GDPR, and PDPL? Yes. It can. Because when looking at those different legislations with legislative protection laws, they have common elements in them. So GDPR, PoPR, PDPL. With regards to how we cover our assessment and do our workshops, the same requirements exist within those different laws with regards to your product non production systems and scrambling personal identifiable information. That is a requirement across all the laws, and it's common. Same with your production requirements. Obviously, the different countries and different locations of the GDPR laws will have different retention requirements on data. But as part of the assessment and part of it, if you are a multinational or global company, part of that workshop, we can document all the necessary requirements whether you have operations in South Africa, Africa, Europe, Middle East, Asia. We can then have that workshop will then cover all those different aspects of it to document those example retention requirements for that relates to those different laws. But, again, it is universal that you need to protect your system with regards to personal identifiable information, and the crux of these laws are all a lot they're quite similarly aligned. Great. I think that concludes all the questions and the webinar for today. Thank you again for joining us, and a big thank you to Rohin for sharing his real world experience. We will be sharing the webinar recording and presentation slides with everyone after the session. If today raised any questions specific to your environment, whether around audits or production versus nonproduction data, please feel free to reach out to us after the session.