Good afternoon or good morning, ladies and gentlemen, welcome to this Ko Cole webinar, understanding the GDPR impact on corporate it. This webinar is supported by Oracle. The speakers today are me. My name is Matthias I'm lead advisor and senior Analyst at Ko Cole. And we will be later joined by Alexei VGA, GDPR business development director, EA of Oracle. Before we start some information about keeping a coal, the obligatory housekeeping, and a look at our today's agenda. First, a brief look at a coal Ko. A coal was founded in 2004. We are headquartered in Germany with a team of international analysts spread across the world, including us UK, APAC and central Europe. We offer neutral advice and expertise in various areas to companies, corporate users, integrators and software manufacturers. And while IAM was our original starting point way back in the time we are now working in the areas of information, security, GRC, and governance, and generally speaking, we cover everything that is important in the areas concerning the digital transformation, our oops, our business areas.
A quick look, we have three business areas. First is research where we provide a wide range of strategic documents and reports, including leadership, compasses, comparing vendors and market segments. We do events and we will have a look at that just on the next slide. And the third area is advisory where we provide vendor independent market expertise to customers which are end users and vendors. Yeah. And that's it for the business areas. Let's have a look at our events and when it says upcoming, that is not fully true because the C I w the consumer identity world Europe is just taking place right now at the moment in Paris, France. And from what I hear it's going well, which it will be followed from the consumer identity world APAC, which will be in Singapore on December 13th and 14th. And if you want to, you can meet me there.
There will be the digital finance world in February next year, which will be located in Frankfurt. And of course there will be again, our flagship event, which is the EIC, the European identity and cloud conference. Again, in Munich, in may some guidelines for the webinar, you are all muted centrally. You don't have to mute, unmute yourself. We control these features. Actually we will record this webinar and the podcast recording along with the slides will be available tomorrow for download for those who have attended, or for those who have registered. And there will be very important, a questions and answers session at the end. And you can your questions anytime using the text based questions feature in the go to webinar control panel. And I ask you to really do that so that we can have a good set of questions. When we start the QM a session as the third part of this webinar, the agenda for today, long names for the individual parts, I will start out with the Analyst view on GDPR as a challenge for any organization operating within the European union security related obligations and their impact on corporate information security, then Anand will join us and he will have a deep dive into the more technological and technical and process oriented aspects from GDPR prompt principles to concrete technical measures, recommended security technologies to address GDPR requirements.
So really implementing compliance. And the third part as already mentioned is the questions and answer sessions. And again, the reminder to add your questions, if you have any of them to cover in the Q and a session later, and that's it for the introduction, and then I will start with my, with my introductory part. So let's first have a look at where we are right now at the moment, a very, very quick introduction, because we are very close to the GDPR actually coming into effect. So we assume, I assume that you are informed of what is going to happen and are more interested in the technological aspect. So very, very quickly, what was the status before the GDPR? Each new member state had its own data protection laws, and all the EU directors had to be transposed into national legislation. And that led to individual national legislation.
Of course, then we had the two years implementation phase with the GDPR entry, inter force, May 25th, 2016. So that was the, the, the beginning of the ticket accounting. It will become applicable on the 25th of May in 2018. And it will be accompanied by national laws. And this implementation phase was made for you and us and everybody to prepare for the GDPR coming into effect in 2018. And with the GDPR, we actually achieve lots of good things. We have a harmonization at EU level, so no individual laws anymore or less for the individual national legislations within the EU, of course, the alignment with technological developments and new factual situations. And lots of things have happened since the original EU directive on data protection came into being, we of course have a strengthening of existing data protection standards. And that is something that we will have a look at on the next slide actually, and very important, very important to our international international audience here is that the GDPR binds businesses outside the EU to European standards when they are operating in the EU or in the European economic area.
So everybody who does business with customers, citizens within the EU are bound to the GDPR and are subject to their obligations. If you look at the data protection principles, these are the, the principles that are aiming at protecting the individuals whose personal data is being collected and processed. And if we look at them just as an overview, that all sounds very great. And it actually is. So we are talking about the principles from lawfulness and fairness of data processing from purpose limitation of the processing of data. So it's really just for one purpose. And the one that actually was meant to be up to accountability. So making sure that there is somebody who is actually accountable and liable for the processing and the storage and the collection of data, and these principles directly lead to principles that are related to PII, personally, identifiable information, and these six key principles are that important enough that I can read them out and we should read them out.
So, first of all, personally, identifiable data must be processed fairly and lawfully. And we've seen that on the slide before. So fairly and lawfully means that we are really trying to make sure that we are, we follow the laws which are required, and that we communicate fairly with our data subject processing and storage must be for specified explicit and legitimate purposes. And that is of course, very important. The, the amount of PII that then is stored in processed needs to be adequate relevant and the minimum necessary. So really only the data that is really needed for achieving the aimed purposes, the information that is stored needs to be accurate and kept up to date. So it needs to be correct, and it should, and it must not kept, it must not be kept longer than necessary. And for all of this, the controllers, which is more or less you, I assume, is responsible and liable to ensure and demonstrate compliance. And that is a very important part to make sure. And this is something that Alexei will have a look later on to really have technologies in place that help you in ensuring and demonstrating compliance.
So what are the challenges that organizations are facing when they want to build systems and processes that are adequately designed and implemented? There are mainly three starting points. The first thing is that we really have to convert the legal requirements, which is the GDPR and other requirements into actual organizational technical and security measures. We really have to transform them into something that makes sense in the real world, although it might, might be it technology. We have to adapt to existing company and industry guidelines on top of that. And we have to make sure that everything that we design is well integrated into our processes. Hopefully it's automated to achieve efficiency, and we have to make sure that all the processes and the technology is continuously improving. And that applies especially to the concrete action areas for GDPR compliance, which are not limited to the following, but which include the following.
So the action areas that we have to look at, and we will dig into that a bit deeper is first of all, a data inventory, you have to make sure, and you have to have technologies in place that help you in identifying and documenting which data is personally identifiable data is stored in which inventory, in which database, in which repository and which processes are built around that, how is it processed? How is it transferred? This needs to be well documented and documented. According to the regulation of the GDPR, we have to have risk awareness. We have to understand where actually the risks are, which are connected to our storage and processing of personally identifiable information. So we really have to understand what does it really mean what we are doing with this data, and what happens if we, if this information is leaking, if this information is destroyed, et cetera, we have to protect the data therefore.
So we have to make sure that data is only accessed during the processes where actually the, the legal basis is available. And protection also might mean encryption also might mean anonymization or minimization or Eurasia could be also data protection. At the right time, we have to prevent data breaches. We have to make sure that technologies and processes are in place to make sure that data breaches are impossible, or at least not very much possible to happen. We have to really make sure that data breaches are prevented, but if they do happen, we have to make sure that there is notification mechanisms in place towards all required stakeholders. And this is in the first place, the data protection authority of your country, or the main country of your organization, where you're operating within the EU and on the second part, most probably also the data subjects and this has to be clarified, but usually data subjects need to be notified as well.
We have to make sure that there is the adequate legitimate ground for processing and storing the data, and that might be consent or a legal contract that makes sure that you have the right to store and process the data. And that needs to be well documented and needs to be made evident whenever required. And the final point, which is not, of course the final point, but then the final point on my list is the implementation of the extended rights of the data's objects, which come with the GDPR, including the right to be forgotten, which is a well known and famous, right? Making sure that you really have the right to have your data erased when there is no other reason for storing this data, except for example, for, for legal purposes.
So what we really want to make sure is that for these act action areas, we have to identify the right things and doing the right thing is described in general, in GDPR S implementing quotes, appropriate technical and organizational measures to ensure a level of security appropriate to the risk. And there, again, I've forgotten appropriate technical and organizational measures is actually what we need to do, and this is doing the right thing. And we have to have a look at two aspects more, of course, but two main aspects first is organizational measures. And we have a short look at that. So we really have to make sure that we do the right organizational measures and these range from understanding your risk exposure, by executing a data protection impact assessments, D P I nominating a data protection officer. In most cases, this will be necessary unless you already have one of course, training for your staff, for your external workforce, for your partners and raising awareness, making sure that there are process in place that people really understand that GDPR is happening and that there are concrete requirements that need to be fulfilled.
And all these measures might also be implemented through contracts, within policies and through agreements with your partners, towards your employees, et cetera. So organizational measures, of course, very important. And on the other hand, you have technical measures and these are as important and they need to be implemented adequately. And this is something where Alessandro will show us much more later on from the overview. There are many measures that need to be implemented, but to go through some very important ones, we have to start with discovering and documenting PII. So we really have to understand where the information actually is stored the PII personally identifiable information. And we have to document that before we haven't done that we cannot protect it. And the same is true for detecting and documenting data flows. Where does this information go for? What purpose and why is that okay, why where's content?
Where is the legal requirement, but also on the more technical point of view, applying relevant patches to all systems, to configure them securely, to encrypt data whenever possible and required, and to control access to data, make sure that only the people or the processes that really should have access to that, to that data have access that needs to be implemented through access control systems and protecting and monitoring administrative accounts is another important aspect because administrative accounts are the ones that could do most harm when misused monitor and audit access apply OD and detect and contained threats are all technical aspects that need to be applied to make sure, for example, to prevent data breaches, to protect your data from, from being yeah, destroyed or, or transferred to source to assistance where you don't want to have them.
So if we take the technical aspect, which we are focusing on today, then the main question is how do we select the right tools to achieve that? So this is the same technical measures, the same box. Then it was on the slide before, but which are the systems that we can use for that. And to be honest, lots of these systems are already within your organization and they need to be leveraged for achieving compliance. And there needs to be a, a choice of which tools are adequate for which, for which measure, and that you really understand, which are the right tools for which control and lots of them are here. And although, again, this list is not complete. There will be much more systems like this, but nevertheless, these systems are already there. Or there are companion product companion systems architectures, which can help you in achieving a technical level of compliance.
And we will see that later on a quick summary of what we published just a few days ago, which is a, a document on maturity levels for GDPR readiness. And this is very much focusing on, on assessing your current status and identifying specific measures in your own GDPR compliance projects and programs, really understanding where you are, where you want to go to, and which are the next steps to take. And this is all very close to the Carnegie mountain capability, maturity model, and all the criteria of course, that are mentioned here are not intended to be comprehensive or complete, but they are really provided to, to exemplify the degree of maturity achieved at each level. So if we have a look at the individual levels, if we start at level one, this is really very, very basic, of course, there's level zero, where nothing has been done, but level one means there is ad hoc and reactive processes in place.
Maybe some fundamental data protection measures and in general, a higher risk of in compliance, which we want to avoid when we think of the fines, which I did not mention today, level two is a, is a level where you at least have understood. There's really something to do. And you have a strategic approach towards GDPR compliance, at least initiated. You have some processes documented and everything is ongoing at still, there is a higher risk of in compliance from our point of view, the level three already means that there are manual and maybe clumsy processes in place, but complete processes in place, which could justify compliance with GDPR. Of course, we won't dare to tell somebody he's compliant, but there should be processes and systems in place which could help you in justifying compliance with GDPR. And this is level three. So what are level four and five level four and five mean higher level of automation and deficiency.
And here technology really comes into play. So enforcement of GDPR compliance, enforced by technical measures. So technology really helps you through automation through through intelligence systems that compliance is achieved very quickly and in an automated manner and level five of course then means that there's also continuous improvement of all processes and technologies. And the final point is very important. Applications, infrastructures and processes are designed and implemented according to the principles of privacy by design and privacy by default. So we really understand that privacy is built within the systems and there it's in the ideal world, no possible to build systems that are not compliant to GDPR, which is of course the final and vision that you want to achieve.
My final slide is of course, about improving maturity, getting to privacy by design and default. And this, after this slide, I will hand over to Alessandro where he can elaborate more on technologies that can achieve this, can achieve this. And in article, article 25 of the GDPR, we have data protection by design and by default. And although there is no concrete recommendation of how that should be done, there is of course a clear vision of how that can be achieved. It can be achieved if we design architectures that have compliance embedded into the implemented processes and these systems, and these architectures are designed that to enable and enforce compliance by default and an ideal world, of course, also to provide evidence of the promised level of confidentiality so that you really can ask the systems how you can really prove and provide evidence for each individual step that you want to provide evidence for that is of course achieved by automation.
And that is something that is built into this architecture as well, to make sure that the systems are working in a way that they implement GDPR on a rule based method so that you can really understand what's going on based on rules. And it's done in the best case automatically these architectures are stable and compliant across system updates. And that, that is of course important because your requirements will change your systems and your business process will change, and that will change. And that is true for on the one hand, homegrown home built systems, self develop systems, but also for commercial of the, of the shelf systems that you use within your organization. And both of them need to be compliant. And these architectures need to make sure that this is stable also across version changes. And the final thing that we look at is that we design architectures that adapt data protection measures to changing requirements, though, that you don't have to adapt your business model, but that your systems and your architectures and your processes are prepared and ready for being GDPR compliant by design and by default. And at that point, I would like to hand over to Alexei and not before I have again, mentioned that you please add your questions to the questions panel in the go to webinar client that is running on your machine right now. And I would like to hand over to Alexandro.
Yes. Yes, I'm I'm here. Thank you Matthias for your introduction. Welcome everybody for this opportunity. I, my name is aand Vaga. I'm Italian. I'm cover a region of Oracle that is a Europe, middle east and Africa with the role of business development for GDPR concerning GDPR. This, this, this law. I also, I am also the founder of a blog writing about GDPR in Italian and English. The blog, you, you can find the blog@europrivacy.info. I'm also part of the board of directors of lsit. That is a security professional association in Italy. And I founded 10 years ago, a community of customers and Oracle partners and consulting firms down to penetration test ERs, auditors, and so on of people interested into security and GDPR received our attention much before it was approved. So we started working on, on this topic because compliance is a very good reason for, for the company to, to invest in security.
My, my speech goes into an explanation about the, the law, those article of the law that have an impact on the, the it and that's move. Disclaimer, legal disclaimer, just, just to tell you that you should seek legal advice from your legal department or, or external companies. You cannot trust too much. What I'm, I'm going to say here. Okay. Going to the point since the GDPR implies the data protection protection of personal data of data subjects, it, and since all data are in it systems, it means that GDPR implies good it and good security, but going a little bit further in this analysis to protect data, you need to know where are the data? So data inventory, where data resides since the law put a lot of emphasis on the protection of the rights and freedom of the data subjects and different processing can produce a different risk profile.
We must be aware both on the consequence of, of a mistake or, or an attack on a specific it systems in terms of right and freedom of, of the data subjects and the security measure. So second dimension in this diagram is risk awareness. We must be aware of the risk, and this is something that was already explained also by Matthias very well. Then when we go and look, the law that the law as 99 articles, and one more than 170, whereas consideration introduction of the law, the law is complex, but there are some articles that can, can fulfilled or must be fulfilled through application modification or leveraging the it architecture. I make an example, when, when you want to acquire a technology that can be installed in the it systems and is agnostic, it doesn't need to know about a specific application. We are speaking about it architecture.
For example, if you install a firewall, a firewall is a solution that goes in the architecture, some other obligation, some other articles that we are going to see in the next slides required by server required application modification. The distinction is important because it's much easier for complex it systems our, our companies to put security in the architecture and when possible it should be put in the architecture. So let's see the next four slide, every dimension, one, one by one. First that inventory, where are the data from the reason is an article that is article 30 records of processing that says that each controller. So every, every company managing personal data shall maintain record of processing activity under its responsibility. So we have, we have to be aware of where is the data, what data are we are, we are managing on the left part of this slide.
You see an abstract of this article. So we have to document each processing with this information. And you can imagine the record of processing like a document, many companies are using just an Excel file to, to create the record of processing. Of course, it also exists on in the market tools to make it, but conceptually it's, it's, it's just a simple document. And so for, for each line in this document, you have to iden to, to show, which is the purpose of the processing. In my example, it's personal Aris, you know, personal enterprises, the judgment that your manager do do about your job, the description of category of data, subject employees, and the category of personal data. In my example, performance and potential, then you also have to put, give information about transfer to third country. And in my example, we assume that this personal data related to personal appraisal are transferred into the us because we are using a talent cloud service, then like explaining the, by Matthias in the principle, we have to, to give information about the limitation time, time limit for a ratio.
So it's reasonable to reduce the risk, to produce the damage to the data subject, reducing the quantity and quality of the data that we keep of them. So in this case, we, we want to say that when working relationship is ended after one month, we are going to delete all the data. And then finally we have security measures. So the law requires us to make a list of security measures that, that we apply to that processing everybody on the market data protection, authority, consulting, legal firm. So they say that this article 30 is just a starting point because you will notice that there's no mention of a list of systems that contains that are used to execute these personal data processing. But if you want to list the security measure applicable, then you have to be aware of, of, of these systems. Second dimension is risk.
Risk is a word very, very often used in this regulation. And so the controller and the processor, so basically the company and it's our source or cloud provider must understand, and must review must reduce the risk for data subject, the risk of producing damage. And in, in some case, in one specific case, the is also a formal obligation to, to do a data protection impact assessment. In any case, what I want to highlight here is what it's written on the right. So data protection, article 29, working party, that is the authority of the authority. It's a group of people operating at a European level that they are, that are representative for every local data protection authority. They produce guidelines and you see that they make reference in these guidelines to, to best practices, to international best practices. And this is a common trend on model laws.
In the past, the laws were more detail in terms of security measures and things to, to be done. Now, they are referring more and more to international best practices that rise the accountability level that we must, that the company has, has, has to be more accountable. We have to make an analysis. We have to understand the risk and we have to be proactive. And, and so on. They, they are not giving us in this law specific detail of technology to be implemented. Some customer of us are worried about that. They would prefer the old style. Give me a list of things that I I will do, but the new law is, is written in this way. Then we have the third dimension articles that are related to the rights of the data subject. And there are a few articles. I, I have a, I TDR 15 to 20 that that require the controller to create the application, give, give the function functionality for right of access, for example.
So the data, the data subject as the right to have knowledge about the data that has been managed by the controller or the processor ratification is my, my data is wrong, please, correct, is I don't want to, to be anymore in your system. Please delete me when we don't agree on ratification or, and some, maybe a third party judge is taking a decision. I have the right to, to, to reduce the, the processing. So you don't have to use my data. And when you have communicated my data to an external company, and you agree that must, this data must be corrected, ratified or erased, you have to communicate these companies also the same, the same request, and finally, right to portability is the right for a data subject to receive an electronic copy in a common format of, of his data, of his data, to be able to maybe to upload to a different provider, a different vendor.
If you look at this article, you will understand that that it's important to have to be aware about the specific application. You cannot, you cannot accept for example, the era, if there are other rights or laws that goes in a different direction, I will not delete your data. If there are pending invoice to be still to be paid, for example, or another law that requires me to keep this data or data portability. As, as another example, I, I, I cannot make anything in the architecture, anything automatic to give a, a copy of your data. I must be aware of the data model of the application. I cannot give you a, a database backup because it contains many other data and of other data subjects. And in any case, this, this is not usable. So these rights of the data subject this chapter three gives a lot of obligation to, to a company that goes necessarily into a evaluation of all specific application of the it.
So I have to go and check if my application is Y Z is able to provide me information for right of access certification measure down to data portability. The fourth dimension is those that the one that is related to security measures, there are several articles in the law where you find that the exact test appropriate technical and organizational measures. So the controller in the process of shall implement appropriate technical and organizational measures. And you find these text in these article 5 24, 25, that has been displayed with more detail by Matthias 28 and so on. But the 32 is the, is the best one that explains with more detail, the, what the regulator mean about technical and organizational mention. When you go and check this article, if you, if you are in it, if you are a security professional, this is the single most important article to be re to, to, to read with with very, with a lot of attention, you will see if you check it that even if it gives more information, it doesn't give a list of things to be done.
It, it says that you have to achieve confidentiality, integrity, and availability, resilience, and so on, but it doesn't say you have to implement this or this other security measure. It doesn't say identity management. It doesn't say log management, data loss prevention, directory services, nothing. It, it doesn't say these things. The only thing that says in terms as an example is encryption, encryption and ation. But I, I, I list here encryption because encryption is a pure security measure that you can put in the architecture without being aware of the, of the, the applications. And, but the, even the encryption is just, just an example. So that doesn't the load. Doesn't say that you have to implement encryption. It says that according to the risk analysis and taking into account the state of the art, the cost of implementation, and many other things, you should evaluate things like, for example, encryption, Evan said, so I, I want to go to the second part of my presentation.
The law does not specify in detail, which security measure shall be applicable. And so you need to, to do basic things to, to start at least the basic thing to start you, you have to know where are the data? You have to understand the risk, and then you have to implement basic security measures and more security again, because even if, because since they don't give us a list of things they do to, to do, they, they will also have the same problem when they, they come to make an inspection, the data protection authority comes to your offices and they, they ask you question which question they will ask. They will probably ask things that are logical, that are reasonable, that are part of the, of the good way of the, the right way to implement it systems. They will refer to international best practice. So they will ask questions about authentication.
How do you authenticate your users or your it, your it personal? How do you authorize them? Do you implement segregation of duty, need to know, least privilege? Do you log, do you create audit and logs? And do you have information that allow you to, to understand that this log has been produced because of an action of a specific person? So accountability, encryption, so anonymization, anonymization, segregation of environment development and test and production separated, and then Dening and configuration management, patching disaster recovery, high availability, back up things that like that. I expected that the data protection authority during the inspection, we'll ask these questions, or at least some of these questions. And we know we have experience because we have been helping our customer with a practice that we call security assessment, that there are very basic mistakes that have been done by our customer in the it department, because its complex he's stratified along the years. And so it department shares password. The developer knows the password that the application is using to have access to the database. They don't log, they make poor patching. There is a lot of room to improve.
So the law is complex. The, the way to be done is long. Where should, where can I recommend you to start? First point is you have to have a record processing because it's mandatory by law. So if you don't comply to article 30, you are violating the law and you, you get immediately a fine, but article 30 is just a starting point. So you can add the technology and analysis by Analyst, by your Analyst, people using tools and software that can help to increase the quality and quantity of the information that you collect in the, in the record of processing. For example, there is a exist technology that gives you a list of system and software inventory. And then you can map the system and software inventory with the, with the record of processing. If you have a system and you, it's not mapping in the record of processing, there are two possibilities.
One that system doesn't have any personal data in, in, in inside. And so that's correct. Or second, you forgot to map a processing and you should amend the record of processing and similar functionalities discovery, sensitive data. So there are assist technology that help a customer to understand if in a specific system database, five system and so on, there are personal data or not. When, when you execute this activity and you increase the record of processing, you build slowly the application and data scope. Initially, it'll be very easy to know which is the single most important system that I have that I I have in my, on premise or, or in the cloud. And then it'll be in subsequent reation of the processing of maintain the record of processing create system and software inventory, discover sensitive data. You will discover more and more, but at the very beginning, you know, already, which is the single most important or the few more, most important systems in Europe in your it.
And so you can start implementing security and we recommend to start with what we call protect the data and the single technology that we recommend to start as the first one is encryption, because encryption has been mentioned as an example, but has been mentioned. It's the only technology mentioned in the law. So start encrypting second point, avoid, avoid using real data we not necessary. It means, for example, do not copy personal data from production to development. And, and if you do that, you are, you are, you are, it's good because in the article five and article, and whereas 26, there are, there are information that it's good if you do it, it's good. If you, if you mask, if you anonymized data, you will, you don't have to comply for that specific environment. But when we, when you encrypt data, it's, it's very clear that you have to have a control on access because encrypting the data, but without having access control, it means nothing because you, you close a window, but you leave open the door.
And when we speak about access control, we mean both access from the personal, from the end user business user, and it person. Then we need to implement monitoring. We block and audit. So we have to collect logs and analyze these logs. It's a, it's a mandatory measure in nowadays in modern ages, modern age, because without logs, you cannot make even a forensic analysis. You cannot give a size to a possible data breach that happened to your premises. And then we have secure configuration. Most of the, most of the security incident that, that, that happened are related to vulnerabilities, wrong, missing patching, obsolete releases and so on. So you need also to, to keep control on secure configuration. When you have cleared the scope, you also go one by one to the application and check, how do they respond to article 15 to 20? And when you have cleared the scope, you can also check other things because in the pink area area that I've discussed, I, I spoke more about technology and needs and requirement that goes in the confidentiality and in the integrity area, but also availability is, is required by the law.
It's mentioned availability in article 32, but availability should be more solid in your system because it's a it's need perceived since many years. However, we have also to take into account availability and enforce good it and good security across the stack. When you have the, the scope clear, you can also give information to the incident management processes that will respond to article 33 and 34 data breach notification to the authority and communication to the data subjects and company risk practices, including data protection, impact assessment, and everything must be documented and everything. And we must keep track of everything we do in this project because a company also has the obligation to be able to, to demonstrate its own compliance. And since compliance here is not black and white, there, there will be judge, there will be judgment. There will be evaluation in terms of best practices and the effort have been done. And the plan being executed even after the, the May 25th, 2000 and, and 18, of course, Oracle has products to help a customer to do all everything that I discussed. I, I, I didn't want to go in deep in the products, but of course we have information. And if you go in the go to GDPR link, so Oracle www Oracle do oracle.com/go to slash GDPR. You, you find many more information in including mapping with, with this scheme to the products and so on.
Yes. Thank you, Alexei. That was great. And really interesting to, to listen to you and to understand how from a non product point of view, how you approach holistic approach towards achieving technical methods and for, for getting more ready for the GDPR. Thank you very much for that. Before we go into the Q and a again, want to remind our audience to add some more questions, some have already arrived, but this is your chance to, to reply, to, to, to get replies to your questions. And so please provide your questions. So where we do, where do we start? So start with the, with the Q and a, and the first question that I had to answer, the first question, there will be a replay. Second, if we look at deletion of information in the system, how far do you go from your point of view? Aand of course, when the user request that information about them is deleted and removed from the system and removed from processing. How, how, how far do you go? Do you look at backups? Do you look at audit blocks? Do you look at some, I don't know, PDF documents, Excel sheets, where documents that are somewhere for, for documentation purposes. How far do you go when it comes to, to deletion of data, this right to be forgotten? What do you think is adequate from your point of view?
Hmm that's, that's a very common question because everybody's worried about right. To be forgotten. And first point, I would like to say that deletion is something that must be addressed in the, in the dimension that in my diagram was called application. So you have to, you have to make an analysis of different application because you cannot, you cannot delete a record just because somebody ask you, you, if, if you receive from, from maybe your Porwal or your contact center, request of access, and then request for deletion, you cannot just implement this deletion. You have to check if it's correct to delete this data. And some, some complexity will be there because you have to check and you have to communicate back back to the data subject. And so a lot of efforts lays there in the analysis. Then the implementation will be quite simple, I think, or in some cases it will be simple.
For example, your, the application you are using or a set of application that you are using will have, or they might have, or they should have, or they will have in any case that I made 2018 functionality to delete the data. And, and then with some time, this deletion will be propagated to other systems. And so, for example, if you have a data warehouse after sometimes this data will be initially maybe just aggregating that it's not anymore a problem from, from this point of view. And then in, in the medium, long term, it will be even deleted the same applies in the backup. There's a lot of discussion about deleting data from the backup.
I've seen the two different position. One is it's, it's not possible to delete from the backup and just wait for the backup to expire, because in any case backup, you don't keep backups forever. So it's, if there is a reasonable timeframe where this backups will be overridden over override it's okay, and the authority will, will accept probably this kind of position. And second is a second position is we keep a record of request for deletion. In case we restore the backup, we will go through this request, but if you keep a, a record of request, you are, you are in a way keeping personal data. Cause you have to, to keep at least some identifier. And so you, you go by, you go back to the, to the original problem. You should be addressed case by case because in some cases it's better to not, not to keep the, the, the log in some other cases. Yes, you could.
Okay. Very closely. Thank you very closely related to that question is the question when data subject requests, the complete set of information in a portable format, from your point of view and your, from your practical approach, does this include also log data, for example, audit log data that you collect for, for internal purposes?
The question is related to the article 20 portability, right? Right,
Right.
Yes. The, the, the, well, I, I'm not legal and I was joking about it. Don't trust me, you should seek your legal advice. However, my impression is that portability is an article that is meant to protect the right of data. Subject to migrate is on information to another provider. For example, from one social network to another one, I, I uploaded a, a life of photographs and I want to migrate away from Facebook to another one, for example. And in that case, this is, this is the right, that is meant to be protected with portability in that case, this is the, the data that I have provided, not the log data. I don't, I don't think the log data, but go back to my initial disclaimer, secure legal advice,
Right? Yeah. As we are both no lawyers, I think that is the, the, in the end, the, the final answer for that, but from our experience and from our expectations as practitioners, we do not expect that log data should be provided in that way, because it's derived data, not the actual core or authoritative data to go back to something that you explained very early. But I think that is very important. You mentioned that encryption is mentioned in the GDPR itself and from the, from the way to, to apply it, what, what do you recommend when it comes to encryption? Is it better to do it in the application, in the database, in the storage? Why, where do you think encryption is, should be applied? And, and what is the, the benefit for that when it comes to GDPR compliance?
Hmm. When, when you speak about compliance, you speak about a need that you have to, to satisfy the, the, for example, the inspection of data protection authority. And so I think encryption in the database would, would be good, provided that you have a, a up to date access control, but the same problem, if you don't want to encrypt the database, you just encrypt the storage. For example, in that case, you have the same problem. You have to have access control. And so encrypting database or encrypting the storage is similar from a certain point of view, the only difference or the most important difference beside the specific plus and minus that are related to the single technology that you are implementing. And of course, Oracle has a lot of experience in that is the quantity of people that have access. Because if you are a, an it per person and you have access to the, to the operating systems, you will have access to the storage.
In that case, the storage, even if it, it is encrypted, it'll be transparent for you. If you, if you encrypted the database, you and you have access to the database, you are a database administrator, it will be transparent for you unless you use additional technology. Like we have one that is called database world. So the it's question of evaluating if the people that works in your it department are a few or many, and if they have different responsibilities, if you segregate a group of people that works in operating systems from the database administrator, it makes sense because it's, it's a limited number of people. It's less, less number of people makes sense to encrypt the database itself beside other, other, other consideration that are more technically on the other side, encrypting on the application. It depends on what you encrypt in any case, every everything that you encrypt must be managed.
Imagine that you, you encrypt the specific data in the application. The application will have access to the, to these data and nobody else. So imagine you encrypt the so names, and then you ask the application, ask the database to give the surnames of person that work. That surname starts with letter a, the database. If the data is, is encrypted, will not be able to answer that. So encryption in the, in the application level as an impact, that must be evaluated. Probably if I design an application from scratch, I can use it. If I don't, it's difficult to add it. After the fact, it's easier to implement encryption in the database and fine grain authorization in the database itself with the database vault when, when we speak about Oracle technology.
Okay. Okay. Thank you for that. Elaborate answer. There's one more question that goes back to the, the deletion issue. If you very simple one, but, but very complex one in the answer. I assume if you can't delete, is it okay to make the information no longer available to hide that data from the system by anonymization? By, I don't know. Yeah. By, by, by replacing it with something different. Is that, is that okay?
No, it's not. Okay. Unless you create a non reversible encryption. So you anonymize the data, encrypting the data on the records that you cannot, that you cannot delete. However, if, if you, if you, if you want to put in place this solution, it means you are going to go into the application, business, logic and data model. You have to have an understanding in that case, it'll be probably the same complexity to real, really, to delete the data. So I don't think it's a good, it's a good idea to anonymize data in a production database also, because when you anonymize data, let's say, change the format, encrypt the data or destroy this data. You will have an impact probably on the application itself because the application are used to have knowledge of the content of the single data. So for example, an address is evaluated by application as an address.
And so if you put garbage in, in the reporting will not work interface to other system, data warehouse will fail and so on. So you need to do a lot of regression. In that case, it's better to make an effort and delete, or another possibility that you have with Oracle technology is to not to delete, but to wide this data with a solution in the architecture that is called label security in combination with virtual private database in basically you add the policy to the database and this policy will make sure that even an application that has been designed before will never receive the lines that have been flagged as a deletion requested. But in any case, when, when going back to, for step, the law requires to delete the data. And so the data must be deleted. It cannot, it's just a partial. So just a partial solution or temporary solution. In some cases, our customer customer are evaluating this virtual private database and label security technology to reduce the complexity of the Deion, but they are deleting in any case at the end.
Okay, thank you for that. We are getting to the, to the close of this webinar, we have more questions left and we cannot answer them within the hour we have for that. So we will get back to those who have sent further questions. And if you do have further questions, please get in touch with us with Aandra or with me, the mail addresses will be on the landing page of this webinar, where will be the recording and the slide tech as well. So please find more information there and just get in touch with Alexandro with me. So we are closing down this webinar. Is there something final you want to tell our audience before we close down Alessandro,
And it was a pleasure to have this opportunity to speak with you. I, of course we have technologies that cover what you explain materials in, in your slide with the tools we have most of them. So my, my, I invite our audience to go to their Oracle representative or to go to www.oracle.com/go to slash GDPR. It's a, it's a good starting point to get further information.
Okay. Thank you very much. Aandra so if there are any further questions, please feel free to get in touch with us, either at Kok or at Oracle, we would be happy to welcome you at one of our events. And there are lots to come and, and then will be greater as always. And we'll, we'll be happy to welcome you to another webinar soon, and that's it for today. Thank you for your time. Thank you, Alessandro for your experience and for your insights. Have a great rest of the day and goodbye to everyone.
Thank you. Bye-bye.
