 You lucked out to have an afternoon session when you could be wide awake after lunch and everything. Today we're gonna talk about GDPR. So if you're not looking for GDPR topics, then this isn't the right presentation for you. Wanted to mention first off that there's some contribution sprints happening this Friday and this is, it's real exciting to take part in sprints if you haven't done it before. So if you're around this Friday, definitely check it out. And there's actually something for everyone. So even if you're not a developer, there's documentation that needs to happen, other things like that. So if you just show up for the sprints and ask for help, the community is always willing to help out and get involved and help first timers and that sort of thing. So feel free to take part in that. Also wanted to mention the upcoming Decouple Drupal days. This is August 17th through 19th. And this is an exciting event focusing a lot on decoupled. But just kind of the future of that part of Drupal. And so look for more information to come out on that soon as far as submitting your sessions, but also just attending, registration, that kind of thing. So it looks like an awesome event. So my name's Dawn Alley. Both Shrop and I work at Media Current. Media Current's a full service digital agency. We work on helping our clients get the most ROI out of their website. And my team, as the digital strategy team, we focus on the content, the data, and the growth part. So GDPR is near and dear to me because I'm one of those people that, I love to chew through data. Like the more data somebody can give me, the more personalized and experienced it can be. So this has a huge impact on the day to day of my team. And I'm Mark Shropshire and I'm the open source security lead at Media Current. And because there's open source in my title, I really have a passion for open source things. Is he first the title or the passion? Maybe both. Okay. It might be a little bit, but I really do have interest in GDPR, other regulatory type things that we have to all work with on our applications and websites. So this seemed like a natural thing for Dawn to kind of take this forward and chat about it today. So two different perspectives, but hopefully it'll give a well-rounded picture of the things that we're gonna look at moving forward. So some disclosures. Y'all, the GDPR is a really, really long document and trying to smash that into an hour is not really possible. We're also not lawyers. So our job today is just to talk about the scoop about the GDPR, some key concepts, talk about the spirit of the law, but we don't replace your lawyers. Like you still have to go talk to the legal side of things to get the full picture. Okay. And today we're gonna kind of just brief through the agenda. We're gonna talk about the guiding principles of GDPR. So just at least a nice outline of what GDPR is about, creating a positive privacy experience, security by design, those some of those concepts, advanced marketing strategies in a post GDPR world. So how do you take these things that you apply to GDPR and how do you actually still do the jobs that we all have to do, the take the tasks we need to do that's important with marketing? And then really important is to make sure that we don't freak out. The deadlines coming, but that we actually have some tips and stuff to help on how to plan for it and how to start today. I'm sure everybody's ready to get to work today after the con. Don't forget our after party though, but we'll talk about that later. But... The action plan second. Exactly. So there is, if you just step back, there's some definite things you can do to move forward from today. And so we'll kick off in the guiding principles of the GDPR, the general data protection regulation, which sounds really fancy. I'm very serious. So who's heard of the GDPR? Who's read the GDPR? Oh, nice, that's awesome. So you can think about the GDPR as a broad set of rights that really focus on protecting the data of EU residents. And that's gonna replace the 1995 data protection directive. So it's known as one of the most important changes to data privacy in the last 20 years. And we're thinking it's gonna impact at least thousands if not more of organizations worldwide. The spirit of the law is really to give users rights to their data and put that ownership back in their hands. So this is greed upon back in April 2016. And you may be asking yourself, why are people talking about this today? And why are things really heating up now? Besides procrastination being an answer, because it is, we have to be compliant by May 28th of this year. I think a lot of businesses were just waiting to understand how the regulatory process would work, how the enforcement would work. And like with anything, there's a broad spectrum on how you can interpret these kinds of regulations and laws. So I think people were playing a little bit of chicken to see who's gonna say what first? Will there be more data coming? And there's still a lot of unknowns, but there's a lot of things that we can take a step forward with today that we do know about. So who's at risk for compliance? If you can say yes to at least one of the following, you should be thinking about GDPR. Do you have international traffic on your website? Do you have CRM or marketing automation platform? Does your site use analytics like Google Analytics? Do you have cookies? Does your website collect personal information? And that could be a contact form or it could be a credit card. It could be very deep. And can users log into your site? And I swear, these are trick questions. The long story short is, yeah, this could impact just about everybody in some way, shape, or form, and should at least take a look at it. So the GDPR isn't just an IT discussion either. So some stats that I pulled through, 89% of companies believe that their competitive advantage is gonna be based on the customer experience, and a strong privacy experience is interchangeable with customer experience in a lot of ways. Consumers are managing 85% of their relationships with enterprise companies without talking to a human being in 2020. So data becomes a huge part of that. In 2015, 43% of cyber attacks targeted small businesses, and then 3.8 million is the cost of a data breach for the average company today, and we anticipate that going up in 2020 to 150 million. So this is one of those topics that it really transcends just IT, it transcends just legal. You have to bring your marketing team, your sales team, your content teams, everybody involved in the conversation. To create that strong privacy and customer experience. All right, so now we can talk a little bit about some GDPR specifics. If you read, so I didn't see anybody that said they read it. I'm sure some people have read part. Okay, some people read it, awesome. I wasn't looking, obviously, I just said a statement. Yeah, so those of you who did, one of the things I noticed when I read through it was immediately there was a lot of information about you see supervisor, authority, controller, processor, data protection officers. So who are these people? Who are these roles? I think it's good to have a little bit of a basis for this. So the data subject at the center, that is the person whose data we're talking about, the person who is gaining rights in GDPR. It could be, it's an individual, so it's the person that you're trying to protect with GDPR here. And then supervisory authority, that is an appointed public authority for an EU member state who you have to report to for breaches and things like that. For a controller, this is the person who actually is responsible for the data. And basically they're kind of the boss of determining who is gonna actually process the data. They kind of document all those pieces. The processor is anybody, so one thing we step back, not only do you need to be GDPR compliant with all the things that Don just talked about, but anybody who processes data for you, so if you send data through a third party, that would be a processor. Even if that, let's say that person or that third party service doesn't really do anything with the data, they don't change the data, maybe they don't even store it, they still have to be GDPR compliant, even just the fact they're involved in the process. So that's really important, I found that to be very interesting. The data protection officer, we'll talk about that a little bit more, but that's a leadership position, kind of like a compliance officer in the organization. So it's real important to have a person who is an expert and this is where it can get a little bit, this is where it's gonna get interesting, I think, to define who is the privacy expert and how do you hire for that, but having somebody... But the CEO of the company doesn't tell this guy any orders with which to accept this as a protection officer, maybe as part of the... Well, and listen to your attorney, so I think that's important, so they're the ones... So with this said, they're the ones who are assessing risk, so if they say, do or don't do that, I think that's good, because everyone's having to assess risk, but yet, so similar to a compliance officer, and I think key to that and what you're getting at right there is real important is that you don't wanna have somebody that can create conflicts of interest within an organization and that's the avoidance, probably where that's coming from is to not set that up. So we'll talk a little bit more about this later, but it's good to read into that, it'll help when you read the document to say, who are they talking about here exactly? So as far as from the overview standpoint, user rights and requirements, there's a few sections here, this is outlined on the actual GDPR official website, but we'll talk through each of these, breach notification, right to access, right to erasure, data portability, privacy by design, and again, the data protection officers are key. Okay, so breach notification, this is kind of an interesting one because all of a sudden 72 hours are mentioned and having, if there is a breach of data that would affect, and this is primarily to affect a, where someone's personal identifiable information is affected in a breach, 72 hours, within 72 hours, there has to be a notification to the supervisory authority. So this means that you have to have everything in order and process internal and your policies and procedures in the company of how you would do the notification. So don't wait, this is the place, don't wait until breach happens, because guess what, a breach will happen, we'll just say that, and everybody get a little chill, but breaches happen and they will happen. So have a plan for when a breach happens, how do you deal with that? Who's responsible, how does that work? And individuals need to be notified if they're impacted. So there's also, like all these, there's a little bit of gotchas and... Shrop, I feel like you just told the future, that a breach will happen. Well, I just believe breaches happen and so it's better to prepare. It'd be great if they don't, right? But it's better to prepare so that you know what to do in case they do. But definitely, this is part of transparency and we'll talk more about that, but you just wanna be open with everyone and make sure that they know what's going on with their data, it's about user rights. So next is the right to access. So what I took away from this section is that EU citizens and the data needs to be owned by them. So they have the right to access their personal data that an organization is maintaining on them. They've got the right to request a copy. I'm sure you've seen some of this in the news and like Facebook updates about get your copy of the data. And then citizens also have the right to know how their data's being processed, shared and how it was originally acquired. So it's giving them a lot more knowledge and power around where that's coming from. You can also have the right to be forgotten. So you can request your personal data to be erased on a number of grounds. So first, if that personal data is no longer necessary, you can ask somebody to erase it. You can ask it for a race for a compliance of a legal requirement or if somebody is not using your data in the right way, you can also ask for it to be erased under those grounds. So the next piece here is data portability and the key points that I like for this section is really to focus on the fact that users have the right to take their data, move that data, export it from one system and be able to provide it to another provider. It could be a competitor, but to another provider and import that data. The key here is to make sure that that is done through a process that is standardized. It's not, this is not a time for vendor lock-in concepts. This is not, I mean, this is an open source conference. So we're not talking a lot about that kind of stuff, but this is not a time for vendor lock-in. This is a time to say, hey, the person wants to leave, they have a right to leave, we're gonna let them export and it's in a format that's a standard, hopefully some open standard, that is easily imported into another system. So, privacy by design, there's a lot of by designs happening today in this talk, but I think the key here is to talk about the fact that we need to think about privacy throughout development of applications, websites, systems that, you know, privacy is one of those things like security, like UX. It's one of these things that we need to think about all the way through and the point here is to not wait to the end of a process, deploy something and go, oh yeah, we're gonna think about some privacy here because at that point, you've probably started collecting data, how your storing data has already been decided, it's too late, I mean, it's not that you can't fix things later, but it makes it much more challenging. So, I really like the concept of a privacy by default stance and that's really to make sure that you are only collecting what you absolutely need to have. So, the days are gone of just kind of collecting everything and just, hey, let's just take everything because we might need it someday. I'm sorry marketers, I both love and hate this too. It is tough to swallow, but when you think about all the benefits to users, and we'll talk more about that, I totally agree, it's a challenge, but you also don't wanna hold onto personal data any longer than you need it. So, you get to a point and you're like, you know, we don't use that data any longer, that's when you start having the conversation, how do we remove that data, how do we archive it, or actually complete removal because archive is taking on another risk that you probably don't wanna have. Yeah, and you know, you can back up that thought about privacy by design even to when you're starting to set big goals for your marketing campaign, taking that into account can set some expectations that have to shift and we'll talk about that a little bit later on, but that's what you reminded me of when you're talking about it. Yeah, it definitely all applies. And so, you notice so far we haven't actually said anything about this, only think about this if you're concerned with people that are members, you know, individuals inside EU member states. The reason we're not really focusing on it so much, that is true with GDPR, and that's an important thing to understand, we believe that GDPR has a lot of great ideas and these concepts, you ought to apply to all of you. Let's just start thinking about this for all users. We'll talk about that some more too, but so here's, so let me jump to the next slide. I got you. Okay. Oh, thanks. Data protection officers. So, this is again, similar role to compliance officers. They need to have expert knowledge of data protection laws. That's the part that's kind of interesting, it'll be interesting to see how entities and organizations standardize on what that means and how that looks and so there are some, like most of these points, there are some places where you may not be required. So, your lawyers may say, well, we're actually not required to have that position. So, mostly here it's for public authorities. So again, more definition has to happen and read into that, but it is important to know that every point we've talked about so far has usually inclusions and exclusions type things that have to be considered. So, we've got some key challenges ahead. Now that we've gotten through like the bulk of the foundation of the GDPR, we could talk about what to do with it. So, some challenges ahead. The implementation requirements are super vague, so is enforcement, compliance and continued process improvements is gonna cost time and money. And then there may be other consequences beyond this, but what we're reading as fines could be up to 20 million or 4% annual global turnover for non-compliance. And I think, well, we don't know how exactly it'll be interpreted or enforced, but my hope is that there's gonna be a spectrum of gross negligence is one thing. Against somebody who's really trying to do the right thing, tries to improve and iterate. But we'll see, there's a lot that we're just gonna find out at the end of May. No anxiety. So, everybody's heard of UX and creating a strong user experience. Today we wanna talk about how to create a positive privacy experience or PX. And I think people hear privacy and data in the same sentence and think of really nefarious activities and we have to change that perception. Data and privacy, it doesn't have to be a scary thing. It doesn't have to be something that happens. The only thing we talk about when something goes wrong. So, some key principles to a strong PX experience. Aim to be transparent with your users. Tell them the full story as much as you can. Don't use lawyer speak. Make sure that the language is easy to understand by anybody. Aim for like a fourth grade reading level. Consent has to be given and not assumed and most cases, if somebody gives you their data, try to protect it to the best of your ability. And don't collect more than absolutely necessary. Empower those users if they wanna be forgotten to be forgotten and then follow those best practices in terms of security and design methodologies. All right, let's talk a little bit about personally thanifiable information. So, on the screen here we've got some examples from this Wikipedia article on what can be considered PI. And you'll see that list. I just said PI, but if you see that, that's just something that in this world it's talked about quite a bit. Here's the challenging part. Not every one of these is always PI. So, this is another interesting thing to deal with. Another risk assessment that has to be handled with your lawyers and with management to say, okay, we look at, so it has a lot to do with how the data's being used. Like full name might be PI as an example, but in certain contexts it may absolutely not be if that full name is publicly known and is all over the place, it may not be. So, what you wanna do is be able to take a list like this and this isn't necessarily exhausted, but it's a good start. But look at anything that might be PI and we'll talk more about that as next steps, but you wanna identify and document and know. I think a lot of people over the years have built applications and sites and they just, somebody wants a new field, marketer says new field, sorry, Don, but. I love seeing new field. New field and no one, other than the field kind of showing up, it's easy in Drupal to add a new field, right? So, other than the field showing up you don't really have any documentation to say that's actually PI or any other classification, frankly, if that matters. So, that's something that you wanna be able to do. So, we'll talk more about how to protect that too. And there are some nice side benefits. Like once you know how you're working with your PI for the GDPR, that'll translate really nicely into the work that you're doing with Google Analytics. So, for example, you shouldn't be passing zip codes or an actual email and a URL into Google Analytics. So, if you're compliant there, you're kinda compliant in a couple other places. So, we wanted to pull together some dos and don'ts in regards to positive PX experience. So, on the dos, the takeaway really is that this is their data. So, you have to know what you're collecting, keep it only for as long as you need to and protect that data with encryption. On the don'ts, don't collect stuff you don't need. And then allow, don't let anybody access that data, really keep it to yourself unless there's a true, legitimate reason to pass it over and you've gotten approval and consent on those things. And that may mean that developers, in my opinion, do not need access to production data. So, if developers have access to production data that has PI, then take a pause, think about that and what that may mean. So, I think that's an important point. So, as far as transparency, you want to really make sure that your policies, your privacy policies are very clear. Don talked about that a minute ago, just having, take out the lawyer speak, that sort of thing. You have to be really clear about with users why you wanna collect data, what it's used for, all the way through the process. And that's not just opinion here, this is getting into GDPR specifics. And users, they have the right, they have the right to opt in. This is not like we've collected your data and now you have to opt out, which has been nice in certain cases in the past, but as you can see, that puts the user first in the situation. And you want to, and again, you just wanna make sure that from a language standpoint that it's easy to understand those policies. We're gonna talk a little bit about blanket consent in a little bit, but that is a thing of the past in a lot of ways. Just because somebody consents one time to one campaign, us as marketers, we can't take their email and campaign and send them other lists too. We have to be very careful about getting consent at each step of the way. So I think we've talked a lot about data portability already, but it's on the dos and don'ts. And then on the don'ts, don't make it hard for users to export their data in a standard way and don't drag your feet and helping them out. That's all you, Shrop, thank you. This is Shrop time right now. Security by design, I love talking about this stuff. And in the past year, I've been talking a lot with some other folks in the room on that. So it's super exciting. But you really, again, I promise the by design, you don't want to wait till launch time and then all of a sudden say, oh yeah, we've gotta think about all these things now. You want to think security from the beginning. So this is the kind of a formal definition of that. But again, it's just to talk through thinking through security from the very beginning. And in my opinion, this needs to be driven by your security policies. So if your organization who owns the web and digital properties, if you don't have like a section of documentation that's actually part of your process plan and review plan every year, and it's really a security plan is what we're talking about. If you don't have that, I would definitely look at, that's a step forward. Talk more about that in a bit, but let those policies and procedures drive your requirements and how you build your applications from the beginning is real important. And so privacy and security software development lifecycle. So anybody that's been inside development projects, application projects and things like that, familiar with SDLC, but the point here is just to say that, again, these are the stages that you would apply security by design through, and you could probably insert some other terms and process that you want. But planning and implementation, testing, all the way through documentation, which is really critical, and then deployment, and then maintenance cycle. So after that, when you're maintaining applications, that's where it can get really challenging because people get excited about new features, stakeholders want this new feature to do this thing, and most new features wind up, there's a lot of new features wind up having some web form that says now we want to collect more information. And so, and that's a great time to talk about a place where your organization stores all content in your content management system. I'm just throwing that out there. It's very challenging, I'm not being, I don't want to make it sound like it's easy, but it's easy to sign up for SaaS services and other things and store data in different places. But I think having those central repositories where you know the data is, and you've got it defined is very helpful. It also means bringing on new systems is something you have to take under advisement there. Next big bucket is messaging and consent. And so this can impact, in these steps, if they're not specific to Drupal, your website, you can rinse and repeat on any platform or tool that you're using. So opting in on a website is different from opting in from an email, but it's still opting in, right? Privacy policy and legal documents definitely need to be updated. If they sound too legally, it might be a good opportunity to talk to your lawyers to see if maybe they can put it in human language and not just lawyer language. Not that lawyers aren't humans, we love lawyers. And then something that I don't think everybody talks about, but it's important to note, there should be some internal messaging that goes out. So if you're on the marketing team, your goals may be different than in the past. And when you're talking to your boss who has these certain goals around, you need to grow the list by this much or this many conversions, or we expect this level of tracking, but you have to set expectations and talk about the value of the PX and the GDPR experience too. As far as user control, again, just that data portability, having plans for that, what does that mean, what data? So once you've defined the data and the data collection points and those integration points, when I have to do an export because of request of data, when we have to revoke consent, we have to follow a racial rights and be forgotten type concepts. How do we plan? How would that work? What fields are affected? What does that look like? So as far as the next steps from here. It's nice when you create a little package for your legal team. So if you do the legwork of tracking down like here's all the integration points, here's all the data, here's what it means. It'll make it a lot easier for them to go through and assess risk. Because a lot of times these are unfamiliar concepts to legal teams. So they're learning the website and the legal side and everybody's interpreting the GDPR. So there's a pretty even playing field. Yeah, they don't need your help to understand the systems that are in place and those audits you've done of your systems and fields and PII. They need that to help make decisions. You can't just say, here's the GDPR. Best of luck lawyers. Because they need to know what does that apply to and your organization that's real important. I think as far, we talked about creating and updating policies enough, but that's definitely important. And you want to, from the findings you have and the decisions made from risk assessments, the outcome should be a list of issues and issue queues and a plan for how you're gonna remediate any issues. How you're gonna deal with encryption. How you're gonna deal with those automations or those exports and data changes. So I think that's important. So it didn't implement those remediations too. So once you've got everything documented, next steps, you gotta rinse and repeat. It's not just the Drupal website, it's really across the board with any kind of technology platform there is today. So it's pretty easy to see the difficulties transforming your company to be compliant with a GDPR but shifting to a focus on a strong PX. I think it's gonna do wonderful things for your relationship with your customers for the positive. And we really feel like this is how the web should work. PX is the new golden rule. It should be how we work with each other, it should be how we treat human beings. So it's a good step in the right direction. I know we had to get into a lot of the legal technicalities and then it can be easy to get stuck in the, oh God, there's so much to do, so much to figure out. How much is this gonna cost me in time and effort? But I think it's gonna really pay off if you embrace the spirit of the law. All right, so I had to talk a little bit about Drupal to wrap this in, because it's DrupalCon and the Shrop is excited. I just wanted to mention there's some progress already happening with GDPR in the Drupal community. And so I think it's important to, we didn't have time to go through all of these, but the deck's gonna be out there and the links are all there in the deck. But there's a really lively discussion about privacy concerns as GDPR compliance. They even got a node number up there, so it's ultra DrupalGeeGee. But that's a good discussion because people are talking through what is PI and how does this affect core Drupal, like the other users tables and things like that in Drupal. But there's some modules here where people have already worked on how do we deal with GDPR in commerce? How do we export? Also the encrypt module, and there's related modules to that, so it's not just that module, but that's important on how do you encrypt that data. And of course, I'm involved with the Garter Security Distribution, which is fun and so we're wanting to incorporate more GDPR in there into that work. There's also a GDPR module that looks like it's making a lot of headway towards addressing concerns and having an API even for some audit type things within your site to work on. I'd like to mention too a shout out to Drush SQL Sanitize for developers that use Drush. That's a great way to put it into your continuous integration workflow so that the developers working on development in lower environments don't have all that data. And of course you may have to script other things to clean things up in your databases, but you really wanna have development happening and when people take laptops away to conferences that they're not walking around with production data with thousands, millions of users and stuff like that. The really important thing here though to end with this is as you come up with solutions around how you're addressing GDPR, even if it's not Drupal specific, but as a company someone's determined that this is how they wanna operate or they've got some ideas around implementation, I just encourage you to give back to the community here. This is the give back part of this presentation where you say I'd like to contribute back to one of these modules and help make it better. So there's tons of opportunity if you've ever wanted to get involved in contributing in Drupal. This is a great opportunity to dive in. And it's not just on the technical side. Media career, we work with a lot of different clients and I can tell you all of the marketing clients we're working with, all of the legal teams, they wanna talk with each other because they're debating internally how to interpret these things and I think putting out your approach in the community at large, not just Drupal specific or not just IT specific would go a long way to helping improve and move things forward, save time. So that's our talk. We definitely wanna hear feedback. We have seven minutes but we're gonna be right after this if we run out of time for questions we're gonna go back to the booth at 525. So come see us for sure. And the after party, 7-Eleven, where you can party away your GDPR concerns. Yeah, find us there, we'll be there. Thank you. I just want to know offhand, do you have an idea whether or not there's like a uniform system where somebody is like an achievement badge and they say that their GDPR compliant because whenever I run a relatively big site and it's the sum of all the third party data tracking software that how GDPR compliant we are, it's very dependent on the third party software. So do you have an idea? I don't think there is one yet. Yeah, I don't know of one. I didn't mention this earlier. There are lots of third party, there's certainly contractors and companies that specialize in GDPR compliance that can help with that. And, you know, but I don't know of anything yet. Tell me else in the room, I know that's like ISO 270001 or something like that where you can put something on your site and say that we are. That's a good idea. Yeah, that probably will come after the end of May. I'm sure you could start a business doing that. I have like a million questions actually, but two, can I fit two? And so the first one is, how does something like Google Analytics tracking users count against this? Is that in a separate world or are we accountable for actually providing GA tracking on from our site to the user? Yeah, so I'm not a lawyer and I've had different lawyers of my clients interpret that on like two ends of the spectrum. So I have one client who says, Don, you cannot fire any Google Analytics cookies whatsoever until somebody says yes, I support you doing that. And that does crazy things to their data. On the other end, I have a client that has said that this is okay to be passive consent, that as long as we're not pushing anything, PII in any way, it's okay to collect general usage data. So it's talk to your lawyers to see where level is risk. Yeah, they want to take on. So the second question briefly is, it has to do with cookies and it's been explained to me perhaps incorrectly that there are three categories of cookies in GDPR. There is what's called required. There is, which is like your login cookie. There's something called functional and there's something called advertising. It's really nice to put that in your package for your lawyers. So what's happened in my company is that the marketing team has decided that everything is required. Problem solved. I mean, not everything's required. So someone's gonna, if there's ever any action on GDPR, then they're gonna look at that and they'll tell you where you're wrong or where the person made the decision. I wish they would give us examples up front. They may say, well, good try, but so it's probably good to look at those. Like session cookies, for instance, are different than marketing tracking cookies and things like that. Right, well, we have our own types of marketing and tracking cookies, which are not third party, but they're for personalization. Gotcha. Yeah, personalization is huge in this, for sure. And so it's a good reason to talk somebody into opting in. Right, yep. Well, I'm guessing, yeah. It's, yeah. That'll be a fun conversation between you and marketing. I understand you're not lawyers, but I'm curious to- It's good to see you again. Hi. I was wondering if you could share Michael's opinion on where PII stops or how far it extends, rather, you know, it's the GDPR is intentionally vague with things like anything directly or indirectly that can identify a user like physical location. Well, address, that counts as address because it's address states count. Because states count, does that mean time zones count? If time zones count, does that include time stamps? If we could collect peak usage time of users? I was wondering if you could expand maybe where you currently stand or how you understand how far that extends. It's like, my concern is like, are our Apache access logs? Do those fall under GDPR? They could. Logs can, IP addresses. You didn't mention IP, but I know that was probably next on the list. I feel confident IP addresses are. Yeah, that's a good call. But like, how far can we- Like, are our time stamps and our database records, are those subject? I mean, so here's what this is about, in my opinion, not lawyer. Is it's about taking those independent pieces of data? Can you build a profile and really identify who that is? That's where it gets into the play. Now, time is obviously a factor that can help identify people. In a log, personally, I don't see that usually in a general sense as much of an issue, but I definitely see like IP, I see, I see, you know, URLs, I see things like that showing up in logs is definitely an issue. Something we didn't talk about a whole lot, but something that's on my mind a lot is backups. Right, that's terrifying. So what are we doing for backups? That's something we need to figure out because, you know, it's great. As a developer, I like to be able to just say, I've got backups way out there, but that's holding stuff. It goes back to the encryption and being able to, you know, delete keys. But we still have to deal with things that don't have those implementations. So it really depends on every project. So just like Don was talking about, PIs is determined in conjunction with, for us, our clients, what we recommend and their attorneys to say this is what we think, because it really comes down to how is it used, how can it be combined? Encrypting this really does help a lot because you're worried about breaches, you're worried about if someone else gets their hands on this. So you may not be doing anything with the IP address or the URLs or some other piece of data, but if someone else gets their hands on that, what can they do with it to put together a profile of somebody? That's what bothers me a lot from a breach standpoint. The encryption's a really good point. I think the less data points you get them, the less of a profile you could build. Yeah. Thanks. Sure. I think this has to be our last question. When do we get kicked out? I think, I don't know. Very soon. Okay. I'm curious about the scenario if your site isn't targeting the European users, maybe if it's not targeting humans at all, you're making for like aliens or robots. Do you still need to be GDPR compliant? So I think it's a good thing to do for other human beings. We have some clients whose legal teams say we can only absolutely do business in the United States, and we are going to scrub. If somebody from Europe comes in, submits data, we're not gonna save that data anyway because we're not gonna use it. So that makes them kind of comply it, right? Because they're not keeping the data, but you have to take the steps to do that. And then I think it comes down to that level of risk that you want to assume. Would the aliens hear you? I mean like extraterrestrials, like extraterrestrials. It's hard to have, it's a website, it's on the internet. So my thing is like, how are you not gonna ever have somebody from EU member state involved with your site? That's, I'm having trouble coming up with scenarios. I guess there probably are, but. But the likelihood of that site being the first one, somebody audits maybe slim. So again, like that risk thing. Got it. Thank you. Yeah, you're welcome. That was a fun question. Yeah, that was good. I liked the UFO action. One more, we'll make it last. Yeah, I would just like to say thank you. First of all, it was very good general overview, but there's a mistake that it said EU citizens, and it's not for EU citizens, it's for EU individuals. So I, as a resident in Europe, even though I'm from the US, my data also has to be compliant with GDPR. That's exactly, you're exactly right. And just a quick advertisement. We created the GDPR audit module. So if anybody would like to talk to us, these two here, or myself. What's your name? Riley. Riley. We're from Brainsome, from Budapest. And we'd be happy to help anybody else. I love the chat, because I'd love to get something like that in garter. And this is crazy complicated. So yeah. Okay. Thank you. Appreciate it. Thanks everybody. Hey, Jim, how you doing? Good to see you. Yeah. Oh, it's nice. So, we didn't want our situation to be like this. Yeah. We had a lawyer committee give the GDPR. Oh, cool. At a recent overseas event. Listen to them more than one. But what about cheese roll? Okay. I had a big problem with it. Okay.