PrivacyA2Z

Blog

  • How to Manage Customer Data Requests Without Calling a Lawyer

    One day you receive an email with the subject line “Delete all my data, now!”. What do you do next? Call your go-to person for legal questions?

    You don’t need a legal team to respond to requests like this—you just need a process to know what to do and when you actually need external help. I will explain the main points and give you some useful tips on how to handle and understand these requests without any issues. By the end of this article, you will have a good understanding of how to handle simple data subject requests. Let’s imagine you are running an e-commerce business or an early-stage startup.

    How do you identify data subject requests?

    We are not going down the rabbit hole here; let’s keep it simple for the sake of clarity. You are most likely to see these main types:

    • Right of Access (DSAR): “Send me all the data you have on me.” Sometimes this is phrased as simply wanting a copy of all the personal information you hold about them. You are expected to hand over a copy of that data.
    • Right to Erasure (“Right to be Forgotten”): “Delete my account and purchase history.” Again, sometimes they want everything wiped. If you use contractors or third-party platforms to process data (including mailing lists, forums, or CMS tools), this includes removing their data from those places as well.
    • Right to Rectification: “Update my personal details.” Sometimes customers notice their address is wrong, or their last name changes after marriage. Most of the time, this is just a simple correction of details.
    • Right to Object / Opt-out: “Stop using my email for marketing.” People subscribe to all sorts of things, and their interests change over time. You must respect this right and stop sending marketing emails when requested.

    …and also, any combination of the above, such as: “What information do you have on me? I don’t want to get any more of your emails!” (which is an access request combined with a marketing opt-out). It is also common for people to ask for their data to be deleted and then, a few weeks later, file an access request just to see if you actually fulfilled their deletion request.

    At this point, I want to highlight some very common mistakes and misunderstandings around these requests.

    First, the request doesn’t always spell out its legal name—and according to the GDPR, it does not need to. If a customer sends a long email and somewhere inside it they mention “…and remove all my information,” you are expected to treat it as a formal request. Sometimes people use generic templates they found on the internet that don’t make much sense, using strange wording or referencing inaccurate things. That doesn’t matter. Even if they cite an unrelated law, if you can understand their overall intent, you must handle it as a valid GDPR request. The request does not even need to mention “GDPR” or include any other ‘magic’ words to be legally binding.

    Second, a request can arrive in any shape or form. It can be a phone call, a text message, an email, or a message sent through the customer support bot on your website. Contrary to common belief, you cannot force your customers to use one specific channel. You can ask them to send an email to a designated address, but they are not obliged to follow that instruction. The same applies to online forms and portal logins—while forcing them through a form would make your life easier, their request remains valid regardless of the medium they choose to use.

    Now, let’s discuss the time limit to respond

    If you don’t know what to look for, you might not even realize you’ve received a request—meanwhile, the clock is already ticking.

    • You have one calendar month to fulfill the request. In practice, this is commonly understood as 30 days from the date you receive it.
    • You should not charge for anything related to fulfilling the request. There are rare exceptions when requests are manifestly unfounded or excessive, but this is not something you should rely on 99.9% of the time. So, we will not discuss it further here.
    • You may encounter situations where you need more than one month if you receive an exceptionally complex request. You can extend your response time by two additional months (one time only), but be aware that citing a lack of staff or saying “it takes too much time” are not valid reasons. The request itself must be inherently complex. Think of extensions as being meant for edge cases, like needing to redact thousands of pages or long video footage.
    • A short note on redaction: A person is entitled to their own information, but you cannot provide personal information belonging to someone else. In many cases, redaction is required so you don’t commit a data breach yourself while answering a request.

    Practical tips for handling requests

    Aside from having a clear process and educating your team, here are a few extra tips for a smooth workflow:

    • Know where your data is stored, what tools you use, and how you can locate customers across your systems. If you have customer profiles, make sure you gather all information connected to them. For example, if you know a customer used a different email address in the past (and you have a record of it), you need to dig up that related information as well. In practice, people often forget that the scope of GDPR covers the entire person, not just a single data point like their current email address.
    • Educate your customer-facing employees so they know how to spot a data subject request and what to do with it. Ideally, you should appoint someone in your organization to track these and ensure their completion. That way, frontline staff can simply forward incoming requests to the right person. All support staff need to know is how to spot a request, what details to note down (like the exact time it was received), and where to send it internally. It’s simple and should be covered in your routine privacy training.
    • Watch out for bad actors. At the same time, don’t forget that malicious actors sometimes try to get hold of other people’s information. You must make sure that data held on one person never ends up in the hands of someone else.
    • Automate where you can. Depending on your size, you can try to automate parts of the process with dedicated privacy tools, but keep in mind that you still need structured data and human oversight to spot and validate requests properly.

    I promised not to go down the rabbit hole, so here is an actionable process you can customize for your needs:

    Step-by-Step Response Process

    You received a request and you understand what they want—so, what do you do now?

    • Step 1: Verify Identity: You have to confirm that the request is coming from the actual account holder. In most cases, you can do this by sending back a quick confirmation. Ask for details you already have on file to verify them—like their name, email, phone number, or delivery address. If the request comes directly from the email address on file and the details match, it’s clear. If it arrives from a completely different address, you may need to ask for extra verification.Stick to information you already hold. If you never collected a government ID number before, you do not need it now to validate who they are. Avoid asking for sensitive documents unless absolutely necessary. This is why companies like to push users to log into their accounts to submit requests—logging in acts as immediate proof of identity. If you would normally trust it’s the right person for a regular customer service issue, that same level of validation is usually sufficient here.
    • Step 2: Map and Audit the Data: This simply means checking your systems (like your order handling system or CRM) using the information you have on the person. Double-check that the records match—for instance, making sure an order belongs to that specific individual, as multiple family members might share an email address.
    • Step 3: Handle Exceptions: This mostly comes up with deletion requests. There will be cases where you cannot fully wipe a customer’s data due to tax laws, legal obligations, or active service requirements (like a product warranty—if you have no record of the order, you can’t honor the warranty). If you must refuse to delete certain data, provide a clear explanation to the customer (e.g., explaining that you are legally required to keep sales invoices for tax audit purposes for X years).If your business is growing, make sure you establish a clear data retention policy that outlines what data is kept, for how long, and why. This makes explaining exceptions much easier.
    • Step 4: Prepare and Send the Response: Gather the documents and put them into a clean, easily readable format. Draft a response letter (using a standard template) answering any specific questions they asked.Deliver the response securely. Sending raw files or sensitive documents via plain email might not be secure enough. However, if you are simply sending a confirmation that their data has been deleted, a plain email is perfectly fine.
    • Step 5: Log the Case: You are required to keep internal records of data requests in case a privacy regulator asks you to demonstrate compliance. Keep a secure log containing the case details, dates, and actions taken. This is also helpful if the same person files another request later on, so you can see your previous history with them. Finally, don’t forget to send a final email confirming to the user that their requested action has been completed.

    Need a Hand Setting This Up?

    This is a simple, high-level overview of what data subject requests look like and the crucial steps you need to take to comply. If a request looks unusually complex or comes from a former employee, make sure to consult a professional before responding.

    Above all, ensure you have an internal system in place to spot these requests the moment they arrive so your 30-day clock doesn’t run out!

    If you have any questions, feel free to contact us—we can help you build a smooth process, educate your team, or audit your current privacy setup.

    FAQ

    1. What do I do if a former employee or customer threatens a GDPR fine to negotiate a refund?

    Separately process their data request and handle the commercial dispute—never combine them or offer to ignore GDPR in exchange for settling. Regulators penalize “blackmail” tactics lightly, but heavily fine businesses that fail to respond within 30 days due to an ongoing argument.

    2. Do we have to delete data stored in offsite system backups and disaster recovery?

    No, provided you put those backups out of active reach. You do not need to immediately restore and edit historical backups; simply mark the user as deleted in your live database so that if a backup is ever restored, their data is immediately re-purposed or purged.

    3. Can an ex-employee request internal Slack messages, Teams chats, or emails mentioning them?

    Yes, but only messages where they are the subject or sender, not every internal discussion. Before releasing internal communications, you must redact all opinions, performance reviews, or personal details belonging to other colleagues to prevent committing a separate privacy breach.

    4. How do I verify a customer’s identity if they no longer have access to their original email address?

    Do not ask for government IDs or passports if you never stored them before. Instead, verify them using “knowledge-based” matching: ask them to confirm specific past transaction details only the real owner would know, such as a specific order number, date of purchase, or the last four digits of the payment card used.

    5. Can a lawyer, relative, or claims agency submit a GDPR request on behalf of a customer?

    Yes, individuals are legally allowed to designate a representative. However, do not hand over any data immediately. You must request written proof of authority (such as a signed Letter of Authority or Power of Attorney) confirming the representative is authorized to act on the customer’s behalf. If they cannot provide signed authorization, you must refuse the disclosure to avoid committing a data breach.

  • Common misconceptions: Thinking the GDPR stops at the European Union’s border

    You are sitting somewhere outside the EU and thinking it’s not a you problem. Or you are sitting inside the EU, but thinking as you use a big US tech company everything is alright. Neither of these are automatically true and if you read below, you will see why.

    In case you are a non-EU based company the GDPR might apply to you as it is purposely extraterritorial scoped. It means regardless that you sitting in the other end of the world it might apply to you, hence you might get even fined. You of course need to meet certain conditions for that, but the bar is not that high as you might think. It is well enough if you run a SaaS company and you advertise your services in the EU or even provide an EU language support line, like German or Swedish.

    The reason for all this is quite straightforward. It would be just too easy to move EU data outside of the EU and then undermine the whole purpose of the regulation. So, the GDPR can only be relevant if it applies to all EU resident’s data, even outside its borders.

    On the other hand, if you are established in the EU and think you automatically in the clear as you work with companies also present in the EU… you can’t automatically claim everything is alright as it’s your responsibility to make sure the services you use are up to the GDPR requirements. It’s just a sometimes-overlooked fact, but we will focus this time on the non-EU countries.

    Non-EU based

    If you are in a list of countries which have an adequacy decision you are mostly in the clear. It means your country’s personal data protection practices are accepted by the EU as adequate to GDPR. This post will not focus on these countries, especially as the list is not so long and missing important countries which have a significant ranking in the world’s service exporting countries, like Singapore, China or India. If there is an interest we can go deeper in these cases as well, but let’s talk about the rest.

    USA, the Elephant in the room

    If your US based company is participating in the EU-US Data Privacy Framework, meaning you self-certify with the DPF. You will need a compliant Privacy Policy Statement which is publicly available and some other steps including an appointed person to handle personal data related requests. The list of companies participating in the DPF can be verified here.

    In case you are not participating you are risking that EU based business will not use your services as it would require extensive verification (and paperwork) from their side on your personal data protection practices.

    Ok, but why the elephant mentioned, if it looks straightforward enough? My response is twofold. There is always debate and – and specially after the Schrems decisions – there is a looming risk of a new court decision which could make the DPF invalid, hence could hinder all data transfer to the US. On the other hand, the US technology and economic dominance makes politically nonviable to really stop all data transfer for long… this means that until there is a real alternative to the US tech for EU companies it is very unlikely there would be any long-term halt for data processing.

    No shield and not on the list? Brace yourselves.

    Rest of the world falls under the same category, regardless if they have their own robust privacy regulation, for example China and its Personal Information Protection Law (PIPL).

    GDPR will apply to you in two cases:

    You offer goods or services to EU residents. One off thing like an EU resident visiting your store in New York would not apply. But in case your company has a setup to target EU residents, then it will apply according to the regulators’ practices. For example, if your company have a German language website offering prices in Euro and placing German language ads on Facebook.

    You are monitoring the behavior of EU residents. This is maybe a little bit less clear, so many US based website blocks visitors from EU countries for this reason. This might be an overkill, but to be safe it practice would be an option if your company uses tools track cookies or the IP addresses of people who visit your website from EU countries, as you would fall under the scope of the GDPR.

    There are two main exceptions when GPDR would not apply: if it’s “purely personal or household activity” or if a “professional or commercial activity” done by a small organization, this case you have simplified requirements to meet.

    Worth to note: There might be conflicting regulations out there, so you might get into a situation where there are competing or even conflicting things you have to comply with. In case its competing, like how many days you have to respond to a deletion request from a customer, the make sense solution would be to comply with the more restrictive regulation to avoid accidental mistakes. In case it is conflicting you might want to rethink your processes first before you try to find a specialist.

    You assessed it applies? So what you have to comply with exactly?

    First of all, remember, the scope of GDPR is the EU residents’ personal data. If you run a company and only a segment of your clients are from the EU, you might choose to only comply with the rules related to them. It means you do not have to overhaul everything; you just need a setup which accommodates the GDPR rules with them!

    So let’s see what GDPR wants you to do in a nutshell:

    • GDPR representative:
    • Lawful basis of processing:
    • Privacy policy:
    • Handle data subject requests:
    • Data Processing Agreements:
    • Manage data transfers:
    • Prepare for data breaches:
    • Records of processing activities*: if you are a startup it’s might not apply…

    All of the above are of course could be written a book about, but everything depends on the details. Even if GDPR applies you might only need a simple time-to-time revised documentation and processes in place to handle requests and report breaches. But it can go in the heights where you need to employ a dedicated team to deal with all this.

    I hope after reading this simplified guide you have a proximate understanding if GDPR applies to your situation or not. I am sure you might have questions, shoot us an email and let’s discuss them!

  • Common misconceptions: What Actually Counts as “Personal Data” Under GDPR?

    We all have experiences dealing with different type of personal data during our daily shopping, web-shops orders, be at our workplace, subscribing to newsletters… not to mention when we want to delete one of our accounts.

    Our experiences vary and sometimes you might feel what happens is not right, but we just don’t want to make a fuss about it or we are simply in a hurry. Maybe we also think, “That is weird, why they ask me that… but some lawyer or someone must have checked it and found it is okay… right?”

    No matter what your profession is, I am sure you also see your peers’ work with a critical eye and spot mistakes much more easily than the average human would do. As data privacy consultants, we do the exact same thing.

    In this post, I would like to explain basic privacy concepts and perhaps help you feel more confident the next time you have to deal with “personal data.” We put personal data in quotes because it is a concept that many people misunderstand.

    Deconstructing the GDPR Personal Data Definition

    According to Article 4 of the GDPR:

    “‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;”

    It is pretty legal and broad, so let’s break it up a little.

    In a nutshell, you should understand it this way: if you are able to piece information together and identify the specific person this information belongs to, then it becomes personal data.

    But what about a simple birthdate, for example? Well, if you only have 05.05.2025 floating in a spreadsheet, it’s not personal data on its own. But if you have the birthday of the oldest person alive in a town, and you also have something else related to it like an eye color, then it is personal data because the crowd has narrowed down to a single human being.

    Most people think personal data must be a name, an email address, a phone number, or a government ID number, but this is simply not the case.

    What Does an “Identifiable Natural Person” Actually Mean?

    To count as personal data, identifying the person has to be reasonably possible. If you would need to hire a private investigator to find out who the person is, then it is likely not personal data.

    Although, with the age of AI, big data, and all our data randomly scattered around the internet, this “reasonable identification” question is going to be an interesting puzzle in the future.

    Also, would a common name like John Doe be personal data? On its own, very unlikely. Unless it is a highly unique name, without any other hints or context you would not be able to identify a specific individual out of thousands of John Does.

    The 3-Part Anonymity Litmus Test

    Because identity can be tricky, European regulators and data protection authorities don’t just guess if data is personal—they run it through a strict, three-part litmus test derived from official EU guidelines.

    To determine if your data has truly broken all ties to a real human being, ask your team these three questions:

    • 1. Singling Out: Can you isolate an individual’s activity from the rest of your users, even without knowing their name? (Example: Tracking a unique browser session that views a specific pair of shoes).
    • 2. Linkability: Can you connect two or more separate records across different systems to the same person? (Example: Linking a user’s anonymous mobile app usage history with their website purchase history).
    • 3. Inference: Can you deduce a person’s traits or identity by looking at the surrounding context of the data? (Example: Correctly guessing who a redacted HR file belongs to by looking at a rare job title and a specific office location).

    How to Use It in Practice

    If your team answers “Yes” to even a single one of these questions, the dataset is legally personal data, and the GDPR applies in full.

    True anonymization requires a definitive “No” to all three. If the data cannot be singled out, cannot be linked to other files, and allows zero inferences, only then is it safely outside the scope of European privacy law.

    The Creepy Side of Location and Tracking Data

    Ok, but what about broad things like location? If you are a customer of a web-shop, they will know where you are when you use their service. The most basic identifier used here is an IP address, which can lead back to a single house or even a specific apartment in a building.

    I would certainly feel my privacy was violated if a random web-shop actively referenced that background data. Imagine receiving an automated email after you bought new headphones online:

    “You must have had a small accident by the poolside at Hotel XY in Tenerife! But no worries, your headphones will be waiting for you at home when you get back from vacation. Buy our insurance now and your next pair will be covered.”

    Here, as always, it depends on what is justifiable. A web-shop has a legitimate interest to protect itself from fraud and malicious actors, so they might temporarily keep logs of your IP address—hence, your location.

    But they should not use that security data in their marketing or sales campaigns. They should be happy with your shipping address for sending you the order, and perhaps keep your city name on record for localized marketing purposes—and not correlate all this background information.

    The GDPR actually asks all data to be used strictly for the specific aim it was collected, and requires those reasons to be explicitly justified. This is exactly why using AI to cross-reference these data points opens up completely new questions and legal dimensions.

    Real-World Compliance Misconceptions

    To round things out, let’s look at three incredibly common scenarios where businesses get the privacy rules completely wrong:

    Myth 1: The Email Loophole

    • The Scenario: A sales representative downloads a list of corporate work emails (like john.doe@company.com) and says, “GDPR only covers private consumers, not people at work.”
    • The Reality: Wrong. A direct work email points to a specific person, meaning these lists must follow the exact same privacy laws. (Note: If the email address is generic, like contact@company.com, then it does not identify a specific person in a big company, and sits outside this rule).

    Myth 2: “We Only Track Machines”

    • The Scenario: A mobile app logs phone serial numbers and IP addresses but no names or accounts, claiming, “We only track machines, not people.”
    • The Reality: Wrong. Device IDs and IP addresses act as unique digital fingerprints. They allow companies to isolate, link, and track a single user’s behavior over time, which legally counts as personal data.

    Myth 3: Anonymous CCTV

    • The Scenario: A store owner installs security cameras that record customers’ faces but says, “We don’t know any of these people’s names or addresses, so it’s not personal data.”
    • The Reality: Wrong. You don’t need a name tag to identify someone. Because the video captures distinct physical traits that allow a business to single out and track an individual’s specific actions, it is protected data.

    Let’s Figure It Out Together

    Did you get a little bit overwhelmed? Don’t worry, you don’t need to have all the answers mapped out. Privacy landscapes can be incredibly complex, and trying to decipher regulatory nuances on your own is a lot to ask.

    Whether you’re looking to untangle a specific data workflow, want to chat through recent compliance updates, or just don’t know where to start, we are here to help. No sales pitch—just a friendly, expert team ready to support you.