GDPR resources are most useful when they clarify how legal requirements affect the systems and processes that handle personal data. This webinar explains how to identify the appropriate legal basis for processing, obtain valid consent, respond to privacy rights requests, manage controller and processor responsibilities, and transfer EU personal data using the required safeguards.
.png)
Hey everyone. We're going to give folks just another minute or two here to filter in, but we will be kicking off the webinar here very soon.
In the meantime, if you've got questions, please put them into the chat box. I will be taking care of those while Donata is doing her presentation, and then we'll make sure to take time to answer all those before everybody heads home for the day.
Okay, let's get things rolling here. Thanks for joining us. First off, my name is Brad McCarty. I run product marketing at FusionAuth and am absolutely thrilled to have Donata Stroink-Skillrud joining us today. Donata, you have a whole lot of letters behind your name too, and that definitely helps as we're talking about GDPR compliance requirements. You were the president of Termageddon — is that the correct pronunciation of the company?
Yep, that's right. Lots of hard names.
Yeah, you guys gave me a challenge today. But looking forward to this discussion. And as I said before we kick this off, if you have questions for Donata, please feel free to put them into the chat — I'll be happy to field those. Without further ado, I'm going to hand over the stage to you. Thanks, Donata.
Awesome. Thank you so much for having me, and thanks everybody for joining us today.
So like Brad said, we're going to be talking about GDPR compliance today. And since that is kind of a legal topic, I do want to note that anything I talk about today is for informational purposes only and does not constitute legal advice. If you are looking for legal advice, I would recommend reaching out to an attorney in your area.
So a little bit about me. As Brad said, I'm the president and legal engineer of Termageddon, which has generated tens of thousands of privacy policies and kept them up to date with changing legislation. I'm also an attorney licensed in Illinois and a certified information privacy professional. At the American Bar Association, I chair the ePrivacy Committee, I'm a member of the Cybersecurity Legal Task Force and the Science and Technology Council, and I'm also the ABA representative to the United Nations.
So I'm excited to talk to you about GDPR today. We'll talk about what GDPR is, what's allowed for processing personal data, and what legal bases are. We're going through more or less the basics of GDPR here because it's such a deep topic — we could break all of these items down into their own presentation, but we'll be scratching the surface and getting to the basics today. We'll talk about consent because that's the legal basis most commonly used for marketing, and also the one most commonly misunderstood. We'll discuss privacy rights, technical and organizational measures — so security measures — the duties of controllers and processors and who they are, how to transfer personal data, and other important requirements. And then we'll have a Q&A at the end like Brad mentioned, so make sure to put your questions in the chat and I'll be happy to answer them.
So let's start off with: what is GDPR? I think most people have heard of GDPR — it's the General Data Protection Regulation, which is an EU privacy law. It went into effect on May 25, 2018, so it's been around for quite a while and there's a lot of guidance, enforcement actions, and fines interpreting its requirements. Basically, it was created to protect the privacy and personal data of residents of the EU. Its goal is to give people control and rights over their personal data and also to simplify the regulations for international businesses.
Now you may be saying, "But Donata, GDPR is so complicated — how does it simplify anything?" Well, if you've dealt with privacy in the United States, you know how difficult it is when each state has its own law and all those laws differ. Essentially, GDPR made sure that each country in the EU does not have a similar patchwork system as we have here. There are very slight variances between countries, but essentially it's pretty much the same — it avoids the whole patchwork mess we have here in the US.
What does GDPR protect? It protects personal data, which is any information that relates to an identified or identifiable individual. That could be names, emails, phone numbers, IP addresses, or information about how people interact with an advertisement or your website. A lot of people think their websites don't collect personal data, but if you have a contact form, account logins, email newsletters, Google Analytics, Facebook ads, LinkedIn Insights, or anything like that, your website is collecting data. Most modern websites will collect data, and there's nothing inherently wrong with collecting data — it's just that you have to meet the requirements of regulations like GDPR.
Now, who does GDPR apply to? First, it applies to the processing of personal data in the context of the activities of an establishment in the European Union — meaning you have an office in the EU, customers in the EU, or subscriptions that people pay you from the EU. If you're not located in the EU, it can also apply to you if you're offering goods or services to residents of the EU or monitoring the behavior of residents of the EU. The first one is pretty straightforward — if you have an e-commerce business shipping to the EU, advertising in the EU, or offering your website in German or French, for example. The second one is where a lot of US businesses get caught up even if they're not directly offering services in the EU. This covers things like analytics or advertising that monitor how people interact with your website or with ads on your website. This means GDPR can apply to you if you meet those conditions even if your business is not located in the EU and even if you've never set foot there. A lot of people think, "Well, I'm not in the EU, so it's impossible for me to get fined" — but actually, a lot of US-based businesses have been fined for GDPR noncompliance even though they're not located in the EU.
GDPR enforcement facts. GDPR is one of the most highly enforced privacy laws in the world. In 2024, there were 2,225 fines issued, and those fines range from a multibillion-dollar company like Facebook to a single person not part of a company at all. So size matters in terms of how much you will get fined, but it doesn't matter as to whether or not you will get fined. Small businesses with one or two employees have been fined. Even individuals with zero businesses have been fined. In 2024, total fines issued came to €4,480,000,000, and the average fine is around €2,000,000. The issues that regulators find most problematic — the ones driving the largest fines — are: lack of legal basis (which we'll discuss), noncompliance with general data processing principles, insufficient information provided to data subjects through the privacy policy, consent banners, or forms, and the inability to maintain information security, which leads to data breaches. So if you've never been subject to a data breach, that does not mean you're off the hook. The largest fines have been issued to Meta, Facebook, Amazon, TikTok, WhatsApp, and Google. But again, there have been a lot of really small businesses getting fined too — just because you're small does not mean you're running under the radar.
Now, principles of processing personal data. These are the requirements for processing personal data. What does "processing" mean? Processing means anything you could do with personal data — collecting, sharing, using, even deleting or destroying that data.
First, you need to have a legal basis for processing that data, and that legal basis must be lawful — meaning appropriate, fair, and transparent. You need to tell people what that legal basis is, and it needs to be the appropriate legal basis. Personal data must be collected for specified, explicit, and legitimate purposes. You need to tell people why you're going to process their data — for example, "I'm going to process your data to add you to an email marketing list," or "I'm going to process your data to send you a contract." Vague language like "we'll use personal data for our business purposes" is not specific and is not legitimate either.
You must only collect and process data that is adequate, relevant, and limited to the stated purpose. If I'm going to sign you up for an email marketing list, all I need is your name and email. I can't collect your Social Security number, passport number, or physical address, because that's not relevant to my purpose and it's not limited to my purpose. Similarly, if I signed you up for an email marketing list and then sent you physical mail to an address, that's not limited to the stated purpose and is not a lawful processing of that data.
Personal data must be accurate and kept up to date — this goes into privacy rights like the right to correct data. If a consumer tells me they just got married and changed their last name, I need to update my records. Personal data must not be retained for longer than is necessary to achieve the purposes for which it was collected. A lot of businesses say "we just keep data forever because maybe we'll need to reach out to this person in the future" — but that's not allowed. If someone unsubscribes from your email list, your purpose has been achieved, so you delete that data. Personal data must be processed only in a manner that ensures the appropriate level of security and confidentiality — those are the technical and organizational measures we'll discuss later. And you must be able to demonstrate compliance: this person consented, this person unsubscribed so we didn't send them any more emails, this person signed up for two-factor authentication and that's the only purpose we used that data for.
Legal basis. GDPR actually prohibits the collection of personal data unless you have a legal basis, and consumers need to be informed of what that legal basis is. You must have one of the following in order to collect or use any of the data that you have.
The first is consent — the individual has agreed to the processing of their personal data. We'll talk about this one specifically a little later because it gets people into a lot of trouble. Usually consent is used for marketing, advertising, and things like that.
The second is contract — I need your information to perform a contract or to take steps the person has requested prior to entering into a contract, like requesting a quote or being sent a copy of a contract. Performance of a contract trips a lot of online businesses up because they think there is no contract. But if you're an e-commerce business selling shoes and someone buys the shoes and you ship them, technically that is a contract — there is an agreement for a specified product, someone pays, and then they receive that product. So for that business, shipping the shoes to the customer would use the contract legal basis.
Processing is also necessary for compliance with a legal obligation to which the controller — the business — is subject, such as the payment of taxes, or needing to process data to comply with privacy laws. For example, if somebody asks you to change their last name, you need to keep a copy of that request in order to demonstrate compliance.
Processing is necessary to protect the vital interests of the data subject or another natural person — interests that are essential to life, like locating someone after a natural disaster. That's not really used for business unless something really bad happens.
Processing for the performance of a task carried out in the public interest or in the exercise of official authority is usually used by the government — like a tax administration agency processing data to collect taxes, or local health authorities tracking COVID exposure during the pandemic. Also not really used by businesses.
And then there is processing necessary for the purposes of the legitimate interests pursued by the business or a third party. This one is tricky. In the EU, you cannot use this legal basis for advertising or marketing — the EU does not consider advertising and marketing a legitimate interest. The UK is currently changing their rules to potentially allow advertising and marketing as a legitimate interest, so this one you have to be extremely careful with because the rules may differ between the EU and the UK post-Brexit. It's also really hard to prove because you have to demonstrate that your interest does not override the fundamental rights and freedoms of the individual. I would not recommend using this one in most cases, and businesses usually need to perform an assessment to make sure those rights are respected.
Your legal basis needs to be appropriate. For example, I can't use the contractual legal basis to send email marketing, because email marketing is not part of a contract. However, if someone has signed a contract and I have to send them invoices, the contract legal basis would be appropriate because that's not marketing — I'm just sending an invoice. The legal basis must be identified — in your website policies, you need to state what legal basis applies to the processing of each type of personal data. You need to document it and be able to prove it. If I'm using the consent legal basis, I need to show that the individual actually consented.
Now, consent. The consent legal basis is usually used for advertising or marketing and is really misunderstood or misused. There are certain factors that determine whether consent was valid.
First, it must be freely given. The person needs to be given a real choice as to whether or not to allow the processing of their personal data. If I sign someone up for email marketing and there is no option to unsubscribe, or a website automatically subscribes users to email marketing and says "we assume that by submitting this form you're okay with email marketing," that's not consent. In addition, if you bundle your privacy policy with a terms of service, that means valid consent was not provided because the individual could say, "I agreed to the terms, but I didn't agree to the privacy policy." Those things must be separated. People also cannot feel compelled to consent, and they cannot endure negative consequences if they do not consent. If a job application form says you need to subscribe to an email newsletter or you won't get the job — that's a lot of negative consequences, so consent has not been validly obtained.
Consent must be specific. The person needs to agree to the specific purposes for which their personal data will be used, and your policies need to state each of those purposes. If you determine you need to use the data for a new purpose, you need to obtain consent for that new purpose. Just because someone is a customer does not mean they consented to receiving email marketing — if you now want to send them marketing, you need to obtain consent for that purpose if it wasn't initially disclosed.
Consent must be informed. The consumer must be provided with certain information for consent to be valid, and usually this information is in the privacy policy. Your policy needs to have a proper list, and that list needs to be complete — for example, a full list of privacy rights and how to exercise them, your contact information so individuals can reach you to exercise those rights, the purposes for collecting data, the consequences of not providing that data, and the legal basis.
And consent must be unambiguous — you need to show that someone actually affirmatively agreed to the processing of their data. Silence, pre-ticked boxes, or inactivity are not sufficient to demonstrate consent. When you go to a lot of websites and there's a cookie consent banner that says "by using this website we're assuming you're okay with the use of cookies," that's not compliant because the individual had no choice. Similarly, a pre-checked checkbox to sign up for email marketing on a contact or checkout form is not sufficient. Someone needs to take an actual action to show they're agreeing to the processing — for example, an unchecked box that says "by checking this box, I agree to sign up for email marketing," which the individual must check to complete the form, or a cookie consent banner with an accept and a decline option that requires the user to click accept for Google Analytics to fire, for example.
Privacy rights. GDPR provides certain privacy rights to residents of the European Union. These rights allow them to gain control over their personal information and their privacy. Your privacy policy needs to list all of these rights plus how individuals can exercise them. When someone submits a data subject request to exercise those rights, you need to respond appropriately and within the allotted period of time.
The first right is the right to transparent information. People have the right to receive information in a concise, transparent, intelligible, and easily accessible way. "Easily accessible" is one that companies take a lot of liberty with. It means your website, usually in the footer, has a clearly visible link to the privacy policy — you can't have light gray text on a slightly lighter gray footer. You can't hide the privacy policy under a "Legal" section or bury it among other policies. It needs to include the word "privacy," it needs to be separate from other policies, and you can't make a user click through ten different pages or scroll through an entire terms of service to find it. When someone sends you a privacy rights request, you have one month from receipt to respond, and your response must also include information about privacy rights. Your response should list all the privacy rights the individual has — so if someone asks you to correct their data, your response also tells them "just so you know, you also have all these other rights and here is how you can exercise them." Privacy information needs to be provided free of charge — you can't charge someone $50 to delete their data. And if you decide not to take action on a privacy rights request (which is allowed in certain circumstances), you need to inform the individual and explain why. There are exceptions to these privacy rights — one example is a legal hold. If you're a German company and an employee who has sexually harassed a colleague requests that all their employment data be deleted, you can decline because it's subject to a legal hold due to the pending lawsuit. But you need to inform that person of the decision so they know their rights request was denied and the reason why.
Right of access. Individuals can contact you and confirm whether or not you process their personal data. When it is being processed, they can also obtain certain information: the purposes of the processing, the categories of personal data being processed, the recipients or categories of recipients (for example, are you sending data to Mailchimp or another email marketing vendor?), how long you keep that data, what their rights are, the fact that they have a right to lodge a complaint with a data protection authority, where you got their personal data from (directly from the consumer, purchased from a data broker, from social media?), whether you use that information for automated decision making and profiling and if so what logic is involved, information about data transfers to third countries, and a copy of the personal data undergoing processing. Note that "third countries" means countries outside the European Union — anything outside the EU is considered a third country from their perspective — so you would need to let the individual know you transferred their data to the United States, Canada, or wherever it went.
Rectification. Individuals have the right to request that inaccurate data be corrected — for example, an email address that changed, a last name that changed, or an address that changed. They also have the right to have incomplete personal data completed, including by providing a supplementary statement.
Erasure — the right to be forgotten. There are certain cases in which an individual has the right to ask their data to be erased from your records. For example: the data is no longer necessary for the purposes for which it was collected (someone was a customer, they're no longer a customer, you have no reason to keep their data); the data subject withdraws consent where processing is based on the consent legal basis; the individual objects to the use of personal data for direct marketing — so if they're sick of getting your emails, direct mail, or ads, they can ask you to delete their data; the personal data has been processed unlawfully; the data has to be erased to comply with a legal obligation; or the personal data was collected in relation to the offer of information society services like online services, apps, websites, or search engines.
There have been cases where someone has gotten a defamatory article removed from Google. For example, a group of people arrested and convicted for fraud had their story appear online, and they argued it was affecting future job opportunities because nobody wanted to hire them. They requested the article be removed, and Google did remove it. Getting a large platform like Google to remove something is more difficult, but data can be removed from websites, apps, and search engines.
Restriction of processing. An individual can request that their data no longer be used for certain purposes. The business can still store the data, but can't actively use it — they could use it for the establishment, defense, or exercise of legal claims, but not for anything else. This applies when the accuracy of the personal data is contested and you're waiting to determine the correct version; when the processing is unlawful but the individual prefers restriction over erasure; when the business no longer needs the data for its stated purposes but needs to keep it for the establishment or defense of legal claims; or when the data subject is objecting to processing under the legitimate interests legal basis and the business needs to verify that the legitimate interest actually exists.
Think of this as a hold on the use of data — you keep it for certain purposes but you're not actively using it for anything else. To use a somewhat bizarre example: say you're selling shoes and a customer says their shoes arrived filled with spiders and they're going to sue you, and they want you to stop processing their data. You're not going to process it for maintaining their account, but you are going to keep it because you're waiting for the lawsuit. You need to keep the record of the shipping and the condition of the shoes when they left your warehouse.
Portability. Individuals have the right to receive their personal data in a structured, commonly used, and machine-readable format, and to transmit that data to another controller. This one seems abstract at first, but it's meant to support a free market. Think about a Facebook account you've had since you were 16 — lots of pictures, posts, connections. If you want to move to another platform, how long would it take to recreate all of that? It would take forever, which discourages people from switching platforms. Portability solves this — it lets you take all of your data from one place and give it to another. A consumer can say "send all my data from this platform to that one" and switch to another provider without having to recreate their entire history.
Objection. The individual can object to the processing of their personal data, and the business must not process that data for those purposes if it's marketing-related. If a person says they don't want to receive marketing from you anymore, that means no email marketing, no direct mail, no phone calls, no texts.
Automated decision making. This means making decisions solely based on automated processing without human involvement, which produces legal effects or similarly significant effects on the person. Think about automatically pre-approving people for a credit card based on their credit score, automatically sorting resumes based on university and GPA, or automatically pre-approving people for loans or apartments. This has to have actual legal effects on someone — it's not like email automations where customers over a year get one email and under a year get another. That's not a legal effect. People have the right to opt out of automated decision making.
Some tips for privacy rights. Your privacy policy needs to list all of the privacy rights provided to people and how they may exercise those rights. Personally, I like to specify who those rights apply to so it's not confusing. Your policy could say "residents of the European Union have the following privacy rights" — because if you just have a list of rights with no information about who they apply to, that's confusing to individuals. Not every consumer knows all the rights their government gives them. It's better if your privacy policy clearly states which rights apply to which people, or that those rights apply to everybody.
Assign a team member to monitor and respond to privacy rights requests. Requests may come from a lot of different places and won't always be labeled clearly. Some people may just submit an email or ticket saying "I don't want this anymore, can you delete my email?" and actually mean delete all their data. Having a person specifically responsible for this means someone is there to spot these requests, flag them, route them appropriately, and do whatever needs to be done.
Now, because there's a time limit, preparing procedures that the team member can follow to respond to these requests is really helpful. For example, if you have a data map, it can help that team member find where the data is kept so it can be deleted quickly — instead of scrambling day-of to find where all this data lives, provide that person with a data map so they know exactly where they need to go. And also what steps they need to follow: do they need to ask other team members to check their emails from this person? Do they need to go into the ticketing system? Do they need to go into DigitalOcean or wherever that data may be kept?
Prepare template responses that can be easily adapted to each privacy rights request. Privacy rights responses need to contain certain information — like the full list of privacy rights and how to exercise them. There's no reason not to have a template, or multiple templates, that the team member can use and then edit. That cuts down on the time and makes sure you're providing the correct information. This isn't something where someone requests data deletion and you respond with "okay, done." There's a list of required information the response needs to contain, so having a template ensures it's all in there.
And be very mindful of the time limits for responses — you only have thirty days, sometimes a little bit more — but once that time limit is up, that's it. If you haven't responded, the individual can file a complaint, you can be investigated for violations, and that's when high fines can be applied. You really don't want that.
Technical and organizational measures. These are basically security measures. GDPR does not necessarily say exactly what measures you need to have, but does provide certain examples. The reason why most, if not all, privacy laws don't specify exactly what you need to do is because security measures change — we've seen a lot of new security risks with AI, for example, that we didn't see fifteen years ago. In addition, certain data needs more protection than other data. A passport number is a lot more sensitive than an email address, so the measures you apply need to be appropriate to ensure that data is secure.
Some examples that GDPR lists — again, these are just examples: encrypting personal data, maintaining backups in case of a physical or technical incident so you can restore that data, maintaining a process for regularly testing security measures (whether that's creating a fake phishing campaign for your employees and seeing who clicks, doing penetration testing, etc.), having a code of conduct for security and ethics, and making sure that anybody processing personal data adheres to your instructions — that includes employees, contractors, and vendors. This is where vendor management comes in: having contracts with your vendors, having an information security policy for your employees, having contracts with your contractors, and providing training. Training is really important because most security incidents are caused by human error. Doing training annually or whenever someone is hired is definitely recommended.
Controllers versus processors. You may have heard these two terms but might not know which one applies to you. A controller determines the purposes and means of processing personal data. A processor processes personal data on behalf of the controller.
For example, say I'm a business owner with an email newsletter list. I'm the one who decided to have a signup form on my website, and I'm the one who determined it needs to collect names and emails. I also have a virtual assistant — not an employee but a contractor — who sends out the monthly email newsletter for me. I provide her with the list and the email, and she sends them out. The VA would be considered a processor because she's processing the email list on my behalf. This is very common with vendors. Mailchimp, for example, would be considered a processor for all of their customers. Same with Stripe, depending on your exact setup. Most of your vendors will be processors.
As the controller, you need to implement technical and organizational measures to demonstrate that processing is taking place in accordance with GDPR. That usually means having a contract covering the actual service, plus a data protection addendum or data processing agreement that governs how that data is supposed to be processed. The processor needs to follow those instructions — if I tell them this is my email list and you can't share it with anybody else, the processor cannot go out and sell it, because that would be against the instructions of the controller. Processors also need to make sure that all individuals processing the data have an obligation of confidentiality — their employees and contractors need to sign NDAs.
Data transfers. Personal data is transferred a lot. If you have an individual in the EU and you're a company located in the US, and that individual submits their email to you, that data was just transferred to the United States. The EU is mindful of the fact that not all countries have these privacy protections. The United States, for example, has no overarching federal privacy law. We have federal laws for healthcare data or the data of children, but not for names and emails, and we don't have a federal right to ask companies to delete those things. We have state-specific laws — some of which provide deletion rights, some of which don't, some of which only apply to large companies. It's a mishmash.
Because the European Union is serious about protecting the personal data and privacy of its residents, personal data can be transferred outside the EU only when certain conditions are met.
The first is an adequacy decision — a European Commission ruling that the country to which data is transferred provides a similar or equivalent level of protection as the European Union. For example, Canada has a federal privacy law, PIPEDA, which provides a very similar set of privacy rights to individuals. Because those systems are very similar, individuals whose data is in Canada will have the same level of protection as if their data stayed in the EU. There is a list of countries that have adequacy decisions.
The second option is appropriate safeguards — making sure that privacy rights and legal remedies are available to EU residents as they would be in the EU. So there are legally binding and enforceable instruments between countries. In the US, we have the EU-US Data Privacy Framework, which is relatively new — an agreement between the two countries that similar privacy rights would be provided. We used to have agreements like this in the past with the EU and they've been consistently struck down, so that one is a little risky to invest heavily in. Apart from that, what most companies use are standard data protection clauses — contractual terms provided by the EU to include in your contracts with vendors when transferring data. You have your vendor sign the data processing addendum, which ensures similar rights are provided to EU residents. That's what most US companies use. There's also a code of conduct or binding corporate rules, such as transferring data between subsidiaries of the same parent company.
One of the main things I wanted to touch on today is that compliance with GDPR does not mean you're compliant with any other privacy laws. This is a very common misconception. Because GDPR is such a comprehensive privacy law, a lot of companies assume they're good to go and don't need to comply with anything else. That's not true. There are other laws in the US, Canada, the United Kingdom, Australia, and other countries, and the requirements of those laws don't necessarily match GDPR's requirements. Just because you're compliant with GDPR does not mean you're compliant with any of these other laws.
For example, US privacy laws can allow an individual to opt out of the sale of their personal information — not a requirement of GDPR. Australia's Privacy Act allows someone to use a pseudonym — not a GDPR privacy right. So if you have a list of GDPR privacy rights, you're not compliant with Australia's law because that list won't include that right. Certain laws have different privacy rights response periods — some give you thirty days, some sixty, some ninety. And privacy policy requirements differ by law: each law has its own list of required disclosures, and those lists don't exactly match up. A GDPR compliance program does not cover all other programs — you do need to figure out which laws apply to you and look at the requirements of each.
Final steps I recommend before we go into the Q&A. Consider hiring a privacy lawyer who can help you create your compliance program — I know that may be out of reach for some businesses depending on cost. Figure out which laws apply to you and what the requirements of those laws are, because each law has separate requirements that don't always overlap. Determine your contractual requirements — you may have signed contracts with clients that have requirements beyond what's in privacy laws, and you still have to follow those. Figure out how to implement those requirements into your compliance program. Update your privacy policy and other external-facing documentation, and keep that documentation updated as new laws go into effect or existing laws change. Create internal policies and procedures for privacy and security. Perform vendor compliance checks and due diligence. And train your employees on privacy and security requirements.
I know that's a lot of steps, but really the first step is figuring out whether you want to hire an attorney or somebody else to do this for you, and then figuring out which laws apply to you — because that's what dictates the requirements you'll be subject to.
Alright, I'm going to stop here. We can go into questions if there are any, Brad. But I'll leave this up so you guys can see my email — if you have any questions afterwards, definitely feel free to send me an email.
Yeah, I got a couple of questions while you were going through some things there. One of them was about practical steps that organizations should take to ensure they can respond to data subject requests within required time frames. You talked a little bit about data mapping and how to make things easier that way — could you go a little deeper on that?
Sure. The first step is figuring out what kind of requests you might get, which depends on the privacy laws that apply to you because each law may have slightly different privacy rights. So figure out what rights you have to provide. Then figure out who is going to take point on these requests — you don't want to get an email saying "please delete my data" and then scramble within your company trying to figure out who knows how to do this. You want to know that ahead of time.
You also want to create procedures. What steps does that person need to take to respond? If I need to correct data, where do I go to change that data? Where do I keep a copy of this request? Where do I go to delete this data? Where does it reside? That's where the data map comes in — you just go down the list. Internally, we have checklists. We say: is this person a customer? If they are, here is the list of where their data may be kept — all the different places — and it's a checklist, so I just check the items off.
Having templates is super helpful because you don't want to reinvent the wheel every single time you have to respond. Usually when people get a privacy rights request, they're automatically stressed because they know the response is very important — a wrong response could get you fined. If you're just writing this up in the heat of the moment, you might miss certain details. So having templated responses for each scenario is really good. We have different templates internally for a data deletion request, a correction request, and even templates for unclear requests. So if someone emails saying "I want to exercise my privacy rights" and doesn't tell us which right they want to exercise, we have a template saying "please let us know which right you'd like to exercise; here are the rights we provide." Or for identity verification — if someone submits an access request wanting all the data your company holds about them, you need to make sure it's actually them. It could be a scammer pretending to be a customer, and if you send that data you've caused a data breach. So we have a template for identity verification: "Send us an email from the email address you registered your account with." Having templates for these various scenarios cuts down the time, cuts down the stress, and makes sure your response is correct.
The world around us is changing pretty quickly, especially as it relates to AI. How is GDPR interacting with other privacy regulations like CCPA, and also with emerging AI governance frameworks?
Yeah. It kind of depends on how a certain country or state wants to do things. In the US we have a messy system. For example, the Connecticut Data Privacy Act recently amended their privacy law to require companies to disclose whether or not they're using AI or inputting data into AI. That's one approach, though it's not a really clean one because the risks posed by AI are different than just regular data processing — that data becomes part of a training set, you can't claw it back, and so on.
GDPR was relatively unique in the sense that it was created with a vision that it would adapt to future technologies. It was deliberately written without specifying exactly what the technologies of today are, so the law would adapt as technology evolves. Exactly how GDPR is going to adapt to AI is difficult to say. I know there have been cases where AI companies collected data illegally, that data was used to train the AI, and the companies were required to delete the entire AI training set — which essentially wipes out the entire AI and the entire business. The EU has also passed the EU AI Act, which doesn't necessarily concern privacy as much — it's more about the development of AI and the types of AI that can be used. But essentially, regulators are saying that the principles of GDPR will still apply to AI products and AI uses. Exactly how that's going to work is difficult to say right now, but it should be applicable.
And do you have resources or template examples anywhere online for people who want to build out their own GDPR templates and make sure they are compliant?
I did write a blog post about this — I'd have to find it because it's been a very long time — but I have published it somewhere. I will send it after this talk.
Great. That's pretty much everything I have — I was just looking through things that came in on chat as well. Yeah, that's pretty much all that we have. Donata, how can people reach you and where can they find you?
I just found the templates and I'm going to put them in the chat here. This blog post has the steps you need to take, and it also has links to pre-written procedures and templates. These are templates, so you have to make sure to adapt them to your business — fill in where you actually keep the data and things like that — but it's a good place to get started. I'll put that in the chat, and I'll also put my email in the chat. That's donata@termageddon.com — you can send me an email there too.
Wonderful. Donata, thank you so much for your time today and for all of the education. And thanks to all of you who attended today. You will get a recording of this sent to your email, so you can always go back and watch it again if there are sections you want to catch up on. Anything else before we take off?
No. Thank you so much for having me.
Thank you, and thanks to everyone for attending today. We'll see you for the next one.
