GDPR 준수:
2026년, 변화된 규정에 맞춰 새롭게 다시 제안되는 SAP 보안솔루션

Welcome to today's session looking at GDPR compliance solutions for SAP. My name is Paul Hammersley. I'm a product owner with EPI-USE Labs, and I've been spending a lot of my time working with some of the solutions that we've built around GDPR, specifically for SAP. Thank you very much for your time today. We appreciate people are incredibly busy. We are packing as much in as we can to this thirty minute session. And if you have any questions, feel free to ask them via the chat panel. Doubt we'll have time at the end. So what we'll do is we'll take all of those questions, consolidate them and provide answers which we'll send out to everybody with the recording afterwards. So please do type your questions as we go through. So in today's session, we are going to start with an update on SAP's data processing agreements and how that affects test systems specifically. And I'll talk about how Data Secure can help with that. Then we will move on to looking at the production environments and two of the specific rights that are contained within the GDPR. After that, I'll talk about the mass cleanup activities that we're doing with some of our customers, and then I'll talk about keeping the data small going on beyond that. So a notice was sent out to SuccessFactors customers towards the end of twenty eighteen advising them that there had been an update to the data processing agreement for SuccessFactors customers and that they needed to be aware of the changes and make any necessary adjustments in their processes by the end of January twenty nineteen. Subsequently, we've seen a more general update of SAP service and support data processing agreements. So this covers all, SAP solutions and anybody which is currently under, a SAP Support agreement. In that update, it now states that the customer shall not store any personal data in non production environments. Now, this slightly contradicts the best practice guides that SAP provide for landscape refresh and poses a new challenge for SAP customers or at least highlights an existing problem which is often overlooked. So in your production ERP environment, there is lots of personal data being processed on a daily basis. Typically, it's employee data, customer data, but there are other types of very sensitive or personal information depending on the industry, depending on how the SAP system is used. That data can be used in interfaces in and out of the system and may also reside in other SAP systems like a standalone HR system or a CRM system. And it may also be going out to pure cloud solutions from SAP or other providers. Hi. Just looking at the ABAP stack production environment, there may be personal data spanning several systems. So you might have customer data being replicated into CRM, employee data in its own system, both of them feeding a BW system and for lots of organizations these systems hold a lot of historical data as well. So it may be customer information for people that haven't bought anything for ten years or more. It could be employee data, for people that left many years ago, or it could be for employees that were part of a company that's since been divested, so isn't actually part of the organization anymore. So this data is no longer relevant for any of the processing, but is still in the systems. And of course, most organizations use some form of copy from production to make the QA and other non production systems, meaning that the current and historical personal data is available in those systems which often have lower authorization controls and sometimes wider availability. So although you may have more users in the production system, you may have users from more organizations in the test systems and development systems. This could be external support partners or outsourcing companies. So this is where Data Secure comes in and it allows you to intelligently mask data in non production environments and it does this consistently between the different systems. A particular business partner and their address on a CRM system will still match the corresponding customer master in the ERP system. That masking capability is also now integrated with Client Sync for masking on exit when making client copies from the production system and also with Object Sync when bringing data down from production to a test system so the data on demand use case can also have the data masked using Data Secure before it leaves the source system. So given this update that SAP have made to the data processing agreements, it makes Data Secure an absolute must for all SAP customers. So with that covered, let's now turn our attention back to the production systems and the complexity and volume of personal data that's stored there. With the GDPR in place, we need to know where data is stored across this environment, and Data Disclose allows us to do that. So this is the first of the applications that we built specifically for GDPR, but we're seeing now has uses for lots of other regions as well as their data privacy laws start to catch up with where the GDPR is led. Data disclose allows us to provide a consistent and thorough response to subject access requests and it can be done quickly. So with the time constraint of needing to respond within a month, this is a very good way to get an encrypted PDF output of somebody's data from across all of these environments and potentially reading in non SAP systems Then in the event of wanting to provide the right to be forgotten, Data Redact allows us to quickly remove or replace just the identifying or sensitive fields without having to archive master data in the related transactions. For many customers, there is also a need to tackle the large volumes of historical data. So this is where our SLO services can assist with a major cleanup project initially, so we can go tackle those customers that are ten years old or more, the employee records that have been divested or just left a long time ago, and we don't feel we have legal grounds for keeping in those systems. The data can be removed or it can just be redacted for less impact and complexity. So, for example, if the records have been redacted, can still report on some of the characteristics of the data that haven't been removed. And then once those volumes are small, we have data retained which will allow the proactive running of retention rules to enforce that the same removal policies that were used in the mass cleanup can now be done periodically as data starts to fall outside of the retention period that's been agreed. So this is the basis of our GDPR compliance suite and we're going to take a look at each of these in detail and have an actual demo of some of these solutions. So we're going to start with the Data Disclose application and this is to respond to subject access requests. So I'm going to switch to an SAP Fiori application and we have dedicated user roles for this solution. So somebody needs to be set up within the SAP system in order to be able to access Data Disclose and we can limit them to the type of data that they want to search. So, in this example, we can search business partners, customers, employees, just person data or vendors. You can create your own additional data types to search and you can restrict specific users to specific types. I'm going to do a search on employee data and I'm going to enter the surname Vogel. We have basic search fields and we have additional search fields and this is also configurable. So you may want to match this to the business process. What does somebody need to provide in order for us to search for that data and provide that data back to them? Do we require email address? Do we require, their former employee number? We can use those things to tailor the selection criteria. It's now searching data across all of the connected systems. So in this example, we've got ERP systems, we've got CRM systems connected, but I also have a connection to SuccessFactors. So with Data Disclose, we provide a capability to use APIs to read non SAP systems and we provide template code for both SuccessFactors and the C4C solution, which organizations can then adapt in order to bring in the data that's relevant for their implementations of those systems. So here the user can see a hit list of any records which match the search and they can choose one or more of these. And the fields that are available here are also configurable. The idea is we give the person enough information to know is this both records that we're interested in or is it only one of these records? Once we've made our selections, we can then go to view the data footprint report and again, this is configurable in terms of what we want to output in this footprint screen and we'll see the different types of personal data listed and the two systems where the data comes from. If we want to see where a particular record is stored in the system, we can click on the data the stored in that back end system. In here, the user can deselect data types. They can actually deselect systems and they can label the systems. They can also add notes to some of these fields. So that annotation will then be visible in the output that we make for the end person. If we do deselect any systems or fields, the PDF output will include a note to say that fields have been excluded or systems have been excluded from the values that were found from the search. So now I'm going to choose to create my output. So I want to send this information to the end user. And if we've had more than one key come up, we can choose which key to make us the main value in the PDF. If we've had more than one name, we can choose which name we want to show in that PDF output. Then I can choose from different company outputs. So in this example, we have different divisions of EPI-USE Labs configured. I'm going to choose the UK output format. That also can be controlled by authorization. So if the SAP system supports multiple companies and we have different users using it for different companies, we can limit them to only be able to provide outputs for their own company. So we then need to provide a password. On the PDF and it creates that encrypted PDF for us to share with the end user. So I'm going to open this now. And we can see I need to enter my password. And then we can see this PDF. So here, we have included the company logo, general information on the organization, and then a statement that's configurable to appear at the top. And then we have a page per system. So here we can see data from the SuccessFactors system and then we can see data from our ERP production system, and any annotations that we've added appear in their own column. We then have a final page where we can add additional text. So if I want to provide information about how the organisation processes subject to access requests, I can do that. In this example, I've also included information for the various regulators in the different countries in which the organisation is working. So the idea with this is that we can very quickly get a very professional output out there to the person that's made that request and reassure them that this organisation understands the requirements of them under GDPR and is taking the legislation very seriously and can be trusted to look after that person's data. So once we've provided that information we may find that the person then comes back to the company and says actually I would like you to remove my data or I'd like you to forget my data. Now it may be that the organisation will remove everything. If it were a customer that hasn't bought anything for ten years, they may decide to remove the name and everything else that could identify the customer. But it could also be that the organization wants to keep some of the information. So a lot of the organizations that have implemented our solutions treat the employee data based on when the person left. So they may decide that actually they always want to keep the identity but depending on how long it is since the person left the organisation, they will redact or remove just specific types of data such as family member information or historical absence information, that type of data. So that's configurable within, the policies that we provide for Data Redact. So let's go back. We're going to do a new search based on a business partner. And in this example, we're going to then assume that the person has requested the right to be forgotten and the person processing this request has looked at the policy and said, this person meets our requirement for the right to be forgotten. So in here, we can see have three systems that have responded and if we go to view the data footprint report, we can see the CRM production system, the ERP production system has data. There's a small amount on the QA system as well, but nowhere near as much information. Having submitted the PDF to the person and then reviewed it, they've said they want to have the data removed. And so the person processing this can now say, I'd like to submit for redaction. So this is the Data Disclose user reviewing the details and saying, yes, this complies with our requirements for removal. And again, they can choose if there's more than one key or if the name appears in different formats, they can choose what to use. And then they can choose the policy for redaction. So I'm going to use this redaction policy and submit that. So this is the end of the process for the Data Disclose user, and we now switch to the Data Redact user. So the Data Redact user has a different set of authorizations, different Fiori application, and their application works basically as an inbox. So if we refresh the inbox, we'll see what's currently in there to be processed for this Data Redact user, and we should now see an entry for our business partner Aguilar this information. The Redact user can also go and view the footprint report. You may want to put things in today to disclose that would help the redact user decide when somebody actually does qualify for removal. But when you're ready to process it, they can simply click on execute redaction. Now this is submitting a job in the back end that uses the Data Secure technology, but with a very specific policy, and I'll talk about that in a moment. Before this runs, let's just go have a look at the data in the back end. So this is my ERP system. Quick overview, business partner information. In here, we will see the data as we saw it in the footprint report. And we'll do the same thing on our CRM system as well while that's thinking. So we can see here's AguaLi record. And I just lost my ERP system. Let me quickly log on again. There we go. So we can go to business partner transaction. And before that job runs, we can see there's our business partner information. Okay. So when this gets kicked off, it uses a specific policy, but that policy is set up in Data Secure and marked as a data redact policy. So this is limiting how the data can be redacted using the Data Secure Engine in a production system. So the normal Data Secure functions, of course, can't run-in a production system because of the risk to production data. So we use this Fiori application with an equivalent SAP GUI application. If you don't want to use Fiori, you don't need to. But we use this as a way of limiting the policy that can be used to actually redact that data. So, when we refresh the Data Redact inbox, you'll see as we come in, it pops up with a message saying that it's checking the consistency of the redaction policy or the redaction policy validity. What we do is we take the policy that's been configured for Data Redact. And we put that policy into a secure encrypted vault. So once the implementation project has gone through and we've tested the exact redact policy that's been set up based on the business needs, we submit the policy to that vault. Each time someone comes into the redact inbox, it checks what's currently set up in the policy compared to what's in that secure vault. So if anything has changed, if there's been any change to the configuration behind that policy in any way it will spot that there's a difference and it will say, We can't use that policy. We can't run Data Redact until somebody validates the changes and pushes that policy back into the vault. So that's how we ensure that it can't either accidentally be changed or somebody tampers with the configuration and affects the way that the data is removed. If we refresh again, now, we can see it's doing that check again, and we can see it now says it's ready to complete redaction. So we can see it's processed successfully. If there have been any errors, we'd be able to view them by viewing the trace message here. And if I go back to my back end systems, go to the BP transaction in CRM, we can see the data now shows as redacted, redacted. Do the same thing on my ERP system. So the record is still present. You can still have transactions that reference this master data, but the master data itself has all the identifying information, perhaps all the sensitive information. Removed or redacted. So you can't link who the person is with their record in the SAP system. So we see this as a much less invasive way of dealing with either the right to be forgotten or just removing data that you no longer have a legal grounds to process. So you still know who the person is, but there's parts of the record that you don't want to keep. So that's the Data Redact solution. Just then going to talk a little bit about our Cleanup services. So, before we start to look at data retain, which is allowing you to keep the retention periods processed automatically, we first will want to look at the large volumes because we've seen customers with sometimes hundreds of thousands of employee records or business partner data or customer masters that they simply shouldn't have in the system anymore. So they've had a retention policy in place that said our retention policy on customer data is ten years, but the IT department saw that retention policy as a minimum for which the data should be stored, not the maximum. So, in many cases, there's a lot of data that needs to be cleaned up in that first, removal. And so we would do that using Data Secure with a specific SLO license. So this allows us to use parallel processing on the data that's being removed and allows us more flexible selection criteria to do that cleanup. The principle is then once the record or the volume is small, we can then use the Data Retain solution to keep that data small. So Data Retain is something that we are still working on. We're starting ramp up later on in February And with Data Retain, we're able to see one object in the context of another object. So it's leveraging the business object workbench that sits inside DSM and all of the integration points that we have between different data to be able to say, go look at a customer, for example, but process the customer by looking at the related sales order information. When was the last order? Once we've checked that, perhaps go and check the warranties. When did their last warranty expire? And using those rules, it will then move those keys into the Data Redact inbox. So what you would see in Data Redact is what we see here where it's a batch submission. So in the batch submission, might see more than one key and those would be automatically put there by data retain. However, in the meantime, we've seen a lot of organizations just wanting to apply retention logic to employee data. So because that is looking at just the employee in its own right and using information about the employee to determine when it should be redacted, we've decided to make that part of the Data Redact solution. So we have a utility for Data Redact. Let's go back into my ERP system. We have a utility for Data Redact that can allow us to automatically process employee leave records. So this is shipped with the Redact solution and we use the function module HR Lever Date to actually calculate when somebody left the organisation. So we can process records based on that. So, if I go to a variant that I have for this, I've got this set up to limit it to some specific employees that I know are leavers in the system and I've set up the number of days since the employee must have left for them to be valid for redaction based on when these employees are there. So I'm going to process this now and you can see here two of these employees have been included in a redaction request. One of them has not been considered valid for redaction. So if we go back to the inbox for Data Redact, we'll now see a batch submission for just those two employees. So this is also something that organisations can use to keep that data volume small when it's specifically around employee and employee leave dates. So we can see in here those two records that have been added and then the Data Redact user having checked that can then go and execute redaction in the same way. Hopefully, that gives you a good overview of where we're at with these solutions. We are continuing to look at the requirements that customers have. We're very keen to hear where organizations are looking for solutions to try and help them meet with the requirements of GDPR. So if we have any areas of interest that you have with your organization, please do reach out to us. We're working on one or two of those, at the moment, and that will be our focus once we've completed the, ramp up of data retain, move that out into general availability. For more information, please do visit our website. There's lots of good information on our GDPR solutions there. There's also some blogs focusing on data security and some of the things that we've seen with organizations implementing these applications. As I said at the start, if you have questions, please feel free to put those into the chat panel. We'll collate them and make them available to everybody when we share the recording afterwards. Finally, thank you very much for your time today. We understand people are incredibly busy. It's great to have so many of you Join. Thanks and have a good day.