Great. So just very briefly about me, my name ISS, I'm the managing partner and DPO at, at a company called tech GDPR. My background is as a CTO and a managing director in the educational sector. And I also several certifications from most importantly, the I a P the international association for privacy professionals. Cause that corresponds a lot to what I do at tech GDPR. I'm the managing partner and DPO. And thank GDPR is an organization that I founded a couple of years ago. And with a, with a small boutique consultancy setting, we are supporting technology companies with GDPR compliance, but also with privacy and a little bit of security as well. And in the cause of doing business and supporting our clients with, with GDPR compliance, we hear the question quite often. So how does security or cyber security relate to the GDPR? What do I need to do on a, on a cyber security site to meet the requirements of the GDPR?
And also does it work the other way around is actually GDPR requirement for cyber security. So, so there's, there's quite a bit of confusion. And what I brought along today with me is a primer on these topics perhaps to, to also quickly tell you I'm also involved in the blockchain topic and the decentralized identity topic that the, that the previous speaker was speaking about is actually something that's very close to my heart. We did help a couple of companies in this space in, in, in blockchain related or blockchain backed decentralized identity or non blockchain backed decentralized identity. So very, very happy to, to catch a couple of minutes of that. I'd like to start this presentation with this kind of unusual photo for a presentation, I would say, but just to illustrate to what, what privacy is, right? So what is actually privacy. If you go to the bathroom, you would expect some privacy, right?
You don't necessarily need secrecy. That's something different. It's not secret what you do on the bathroom. Everyone knows about it. You still like to be uninterrupted and be there by yourself in, in, in your, in your private setting, doing your private business to say, and this is actually something that is very well supported by security or the lock on the door in that case. And if you look at security and privacy, you, you would say that you can have security without privacy, which you cannot have privacy without security. You've gotta need that lock on the door to feel private and to have your privacy. So looking a little bit closer into how this relates also to secrecy, because that's also not the same thing as secrecy. If we look at privacy, we specifically talk about personal data, GDPR or PII in the us American context.
And in secrecy, we, we, we rather talk about trade sequence, financial details, contract details, or access details. And both of them actually require security. So the technical and physical means of protecting information is what we see as security. Now, privacy also needs other things, right? Not only security, privacy also needs transparency, limitations to how data's being processed control for individuals on, on, on how the data is being used and accuracy. And, and this is where you start to see a little bit of a divide between, okay, what is the security needs of privacy? What are the other needs of privacy? And where does the secrecy point come in or, or attached to this, getting to privacy. This, this addresses the rights of individuals to control how, and to what extent information about them is collected in further process. I, I find this one of the best descriptions about privacy.
It also is mostly concerned with personal information and it is not the same as secrecy. And if we look at the GDPR principles around privacy, because GDPR in Europe is the way how privacy the right to privacy, which is a universal human right, is implemented into law and regulations. There are seven principles. I'm not gonna go too deep, but I'd like to share with you the principles of the GDPR. So there is a requirement for data to be processed in a lawful fair and transparent way for data to be processed with a purpose limitation. So data can be collected only for a specific purpose and can be used for that purpose. If, if people are well informed about that, but cannot be easily repurposed, for example. So it's very clear what data is being used for and what it should be useful. Data minimization, only the minimum amount of data required for the indicated purpose may be collected and used and the data needs to be accurate. So there's an accuracy principle. So also the moment the data changes, for example, someone someone's last name changes, then you would need to be able to update those under the regulation of the GDPR, then there's storage limitation. So the data should only be stored for the amount of time that it's necessary to fulfill the specified purpose.
And there's the requirement to have integrity and confidentiality in, in, in the data. And this is also where, where, where most of the security aspects, cybersecurity aspects lean into the side of the GDPR. And I said, seven principles, not six, right? Because all of this is governed by accountability, any organization processing data about individuals that, that have some relationship to the EU or Europe or, or GDPR relevant areas need to take accountability for this, for this, and need to make sure that all these things are being documented and, and clearly laid out. So looking at the, the GDPR, the general data protection regulation, it protects personal data, and it's implemented into cybersecurity mostly by Toms or technical organizational measures, which is a requirement under the GDPR. Now there are no specific requirements that are part of the GDPR. The GDPR doesn't say use AEs 256 bit encryption for this type of data.
No, the GDPR basically says that that anything implemented and security measures need to be appropriate to the kind of data that's being processed. So how to determine what cybersecurity measures are appropriate and how to document such efforts for the, for the GDPR. And, and this is probably one of the most asked questions and, and something that we as a company support with, but, but doing this presentation, try to give you a little bit of direction into what to look at now, cybersecurity, the lock on the door is ensuring the confidentiality, integrity and availability of information assets, including personal data or BII. And it's mostly concerned with confidential data, but as we've seen before, not only, and it's also needed where we are processing personal data to meet those requirements of implementing appropriate technical and organizational measures of the GDPR. Okay. What I'd like to take you through is a little bit of like what alignment is there between cyber security and, and GDPR.
Now we'll go quite, quite quickly in the interest of time. And I brought a classical symbol in traffic light system with me to indicate, is this great? Or is this not so great? Right? So first of all, there's this a risk based approach. If we look at certain standards, innovative standards, like the ISO 27 0 0 1, there are explicit risk management requirements and in the GDPR, in the privacy implementation, they're also risk based requirements that take into account the state of the arts because of the implementation nature, scope, context and purposes of processing. And, and there is actually also inferred OLS. There's a lot of focus on these specific risks. So this is, there's quite a bit of alignment in the area of risk. There also some common principles, integrity, availability, accuracy, confidentiality, and this accountability basically appears on, on both sides of the table in particular, if you compare it to normative standards such as those over the ISO.
So that's also good if we do, if we look at some specifics, such as brief breach notification, there's actually the, the management of information security incidents need to be, need to be managed under the ISO 27,001. And under the GDPR, there are also specific requirements. So this is, I would say certainly more specific to report or supervisory authorities about breaches to have specific reporting requirements and to inform data subjects if there's a high risk to their privacy. So I would say the GDPR is a little bit more specific, but there's still quite a bit of alignment in between the two privacy by design. Very interesting requirement. If, if, if we look at, at, at, at the GDPR where we are required to build products and services in such a way that privacy is implemented from the beginning, if you look at ISO 27,000 thousand one, there's also the requirement information security is an integral part of information systems across the entire life cycle, of course, more focused on security than privacy, but the GDPR also has these requirements under data protection by design and data protection by default.
So the privacy perspective here is that the products need to be built while taking the privacy scenarios and the privacy threats and the privacy threat actors and remediations to, to certain threats into account, for example, through requirements engineering, to counter these specific risks. So there's great alignment here as well, asset management, and on the asset management side, we see that there's some alignment as well with the ISO 27,000 controls to understand what personal data is involved and where it is stored, how long region who is access, et cetera. And article 30 of the GDPR also requires us to understand what personal data data is involved and how it is being stored. So these are all GDPR requirements. So again, we see quite a bit of alignments here, re supplier relationships is also something where under cybersecurity controls, we, we look at the protection of the organization's assets that are accessible by suppliers and under the GDP.
They're very specific requirements. Again, looking at contracting and supplier to specifically process data in, in, in specific ways and have also formalized agreement with them under the GDPR. You can only use a supplier for processing your data if you have a formalized data processing agreement. So also good alignment. Now, some things where there may not be so great alignment. So obligations, for example, under cybersecurity, the obligations are not clearly harmonized where under, under GDPR, we have collection limitation. We have openness of information, relevancy, usage, limitation, et cetera. If we look at confidentiality, we see that in cybersecurity, this is fully implemented, always as a requirement in the framework of security, but under privacy and, and GDPR, we see that personal data is not always private. Think about the phone book, for example, there's not always a notion of confidentiality. So, so there's not so much alignment here.
And we see going in into few different directions here, information classification, certainly on the cybersecurity. There are, there are fairly harmonized ways of, of justifying information, but under the GDPR, we, we basically only have personal data, special categories of personal data. Now further classification of personal information also helps with building better privacy implementations or privacy systems by for example, defining specific controls for specific data. But the, the notion of, of top secret information doesn't really apply to the GDPR over there. We just talk about personal data. And one piece of personal data may be very, very similar to another piece of personal data. While there cyber security. There may be a difference between confidential and top secret classified information. So not so much alignment. And, and that makes it a little bit trickier. So you can have security with privacy, but you cannot have privacy without security.
So for example, privacy, enabling technologies can be cybersecurity technique as well as a privacy nightmare, if they're too invasive or incorrectly applied. So the question then comes like what security measures to implement to meet the GDPR requirements. So the question or the answer that, that, that, that most people in this space would give is like, it depends. And it does depend also on what types of data are being processed. We're talking about email or health data, which would be considered a special category on the GDPR and also requires additional controls. What's the scale of processing and what is the privacy risk to the individual, if something were to happen. So these are all the elements that the implementers would need to consider, but there's one, one thing that one can do in certain cases is to move data out of scope of the G of the GDPR by truly anonymizing it very interesting, very difficult, and, and can only solve certain problems and meet certain requirements in certain situations.
Then in terms of protecting data, we can Ize encrypt access controls in place, backup, logging, intrusion detection, all these things are fairly standard and fairly, relatively common practice to, to put this in place wherever possible and feasible. Now the GDP then indeed requires appropriate measures, right? So the controller process should implement appropriate technical organizational measures to ensure level of security appropriate to the risk. Looking a little bit deeper into that. One should also take into accounts, the likelihood and the severity of the, of the risk and, and they should be determined by referencing to the nature scope, context and purposes of the processing and risk is to be evaluated on the base of an objective assessment a little bit further. And I won't read all of this out, but basically one has to look at an assessment in the terms of origin, nature, likelihood, and severity, and the identification of the best practices to mitigate the risk.
I'm actually on my last slide, I see that someone is already standing up. So let me, let me close with saying that guidelines provided by the, by the board, by, by other supervisory, authorities may give some indication, but in the end you would need to find out for yourself what are the appropriate measures to put in place to protect information, personal data via AI, the GDPR. So that's it for me. Thank you so much. And if you like to reach out, please do so send me an email, have a look at our website, or perhaps just find me on LinkedIn. Thank you so much.