Understanding GDPR

July 14, 2022

GDPR and ePrivacy principles: Understanding the big picture


The EU’s data protection and privacy framework has for many global companies become the de facto standard: Because their rules around the use of personal data are so well delineated, and the penalties for violating them so severe, many companies have decided to apply the EU’s GDPR principles and ePrivacy principles as their own data protection and privacy principles across the globe. 

And it makes sense: Doing privacy and data protection compliance is hard as it is. Trying to figure out where one law applies and another doesn’t in a global marketplace is even harder. Rather than parse out which customer is residing in which jurisdiction, it can be easier to find a “lowest common denominator” of privacy law and simply apply that across the enterprise. 

However, no company goes from zero to compliance in a single day. As you begin your journey to ensure you’re handling personal data legally and without fear of legal consequence — or reputational damage from consumers — it’s important that you first grasp the major concepts of the GDPR and ePrivacy before you start to operationalize all the fine details of compliance.

Let’s take a look at some GDPR principles explained. As you read along, you’ll find we most often refer to Recital 39 of the GDPR, as well as Articles 5 through 11. It certainly can’t hurt to read through those first or to at least keep them bookmarked for future reference.

Lawfulness, fairness, and transparency

While all of the principles of European privacy and data protection are important, it’s easy to argue that this is the one principle that rules them all. It’s the principle the text takes the most time with, and it’s the underpinning for everything else that follows. It breaks down into these two golden rules:

  • Before you process (the EU tends to use the word “process” as an all-encompassing word for collecting, storing, using, etc.) any personal data, you should know exactly why it’s legal for you to do so.
  • Every time a data subject (this is the EU’s term for “person” in a privacy context) provides you with personal data, they should know exactly who they’re dealing with and how you’re going to use their data.

In large part, as long as you follow these two basic rules, it’s hard to get into too much trouble, though there are plenty of details to sort out there. Three pieces that might not be obvious:

  • Part of “transparency” in the EU is making sure data subjects always have contact information if they need further explanation or want to object to something you’re doing.
  • Similarly, you have to tell people what their rights are to their data every time you ask to collect data, and you have to explain what the risks might be if they provide you with the data. You can’t assume that people know the law or that they understand what risks they might be taking. “Buyer beware” is not a thing with EU data privacy principles.
  • You have to explain exactly what you’re going to do with the data at the time of collection. It’s patently unfair in EU data protection principles to collect data and figure out how to use it later. This can be a headache for people trying to do “big data” or basic data analysis.

As a guiding idea, over-communicate. The more you explain what you’re doing, the more fair the transaction with the data subject will be. However, make sure you don’t bury the details in giant walls of text: Part of transparency is always communication in a clear and easy-to-understand fashion.

Purpose limitation

Obviously, this follows closely on from the fairness and transparency principle: You should only use data for the purpose it was collected for in the first place. Full stop. It’s not “fair” to just process personal data however you want just to see what might happen.

Article 5 is clear that personal data should only be “collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes.” There is a limited carve-out, however, for data archiving or research if it provides a benefit to the public interest.

Just be wary: You’ll have to back up that claim with a demonstration of what that benefit is.

That’s why it’s important to be clear in your communications. If you say in plain language in a prominent place that you’d like to have the option in the future of doing complex data analysis as part of research your organization is doing, and the data subjects consent to that, then you’re fine to do that.

But purpose limitation goes even farther than that: As Recital 39 says, “Personal data should be processed only if the purpose of the processing could not reasonably be fulfilled by other means.” So, even if you get consent and everything is “legal,” you still may be violating EU data privacy principles by processing data when you don’t really need to.

Data minimization

This one is pretty straightforward, even if it’s in opposition to some conventional wisdom here in the United States. The personal data you collect and process should be “adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed.”

In short: You should only collect data you actually need to do the thing you want to do. Don’t collect more than you need.

Of course, ever since storage has become relatively inexpensive, many organizations have collected information by default. Why not? You never know what you might need later on. However, this is simply unacceptable in the EU.


Remember that European privacy and data protection principles are primarily concerned with reducing the harm people cause by mishandling data. Just as it can be harmful if someone uses your data without your consent, it can also be extremely harmful if data is inaccurate.

Therefore, the GDPR says it’s only fair that if you collect personal data you also ensure that it’s accurate, and that you give people the opportunity to correct it if necessary.

Inaccuracy can cause all kinds of harm. Imagine if a person supplies information to a potential landlord about a previous rental relationship, and because you have the person’s name wrong in your database, you tell a reference-seeker that you have no record of the person. That might lead to serious harm in not being able to find housing.

Further, accuracy is important even if it’s not your fault. Just because the data subject may have entered the wrong information doesn’t mean you don’t have an obligation to ensure its accuracy going forward: “Every reasonable step should be taken to ensure that personal data which are inaccurate are rectified or deleted.”

The question, obviously, is what is “reasonable.” This is still shaking out in the EU, so err on the side of caution as you think about accuracy and the GDPR.

Storage limitation

This may seem obvious at this point, but just as you should only collect the data you need, you should also only keep the data you need. Once you’ve used the data for the purpose you collected it, you’re then obligated to get rid of it unless you have a valid legal reason for keeping it. 

For example, you might need it it to:

  • Protect you or the data subject against legal action in the future
  • Continue supplying a benefit to the public interest
  • Perform research in the future that will supply public benefit
  • Comply with a request from law enforcement

However, the GDPR’s recitals are pretty explicit: Storage limitation “requires, in particular, ensuring that the period for which the personal data are stored is limited to a strict minimum.” Further, “In order to ensure that the personal data are not kept longer than necessary, time limits should be established by the controller for erasure or for a periodic review.”

As you think about operationalizing privacy, this is a big one. Each piece of data you collect should be immediately tagged with some kind of time frame for review and potential deletion. 

One other thing to consider is anonymization, or what the GDPR refers to as pseudonymization (because people in the EU are skeptical true anonymization is possible). You can store data for as long as you want as long as you anonymize it and it can no longer be linked back to the data subjects who provided it. But walk carefully here — data scientists are really good at figuring out ways to de-anonymize data. If you have a breach, and the breachers can link the data back to actual people, regulators aren’t going to care that you thought your anonymization software worked fine.

Integrity and confidentiality (or ‘security’)

This one is pretty basic and easy to understand: “Personal data should be processed in a manner that ensures appropriate security and confidentiality of the personal data, including for preventing unauthorised access to or use of personal data and the equipment used for the processing.”

EU laws says you have access control measures that meet basic industry standards in order to insure GDPR confidentiality.

What are the basic industry standards for information security? Good question! Obviously, the answer is a moving target, as there are improvements in security technology released nearly every day to combat increasingly clever attempts at unauthorized access by hackers and other ne’er-do-wells.

However, there are some basic tenets that should help you out:

  • Encryption goes a long way. If your data is encrypted at rest and when in transit, regulators feel that provides solid confidentiality. If hackers get in, and the data was not encrypted, you’re going to have a bad time.
  • Make sure you have adequate back-up procedures and policies (which gets to “integrity”). The GDPR considers the destruction of personal data by mistake or accident almost as bad as unauthorized access. Remember that you’re just a caretaker of someone’s personal data — if you lose it, it’s just like you losing someone’s personal property.
  • Document your decision-making. What information did you rely on to assure yourself that your security efforts are in line with current best practices?

If you do experience an unauthorized access or a loss of personal data, you’ll need to assess the risks to the rights and freedoms of the data subjects to which the personal data relates and may have to notify either a country’s data protection authority or the data subjects in question – or both.


This seventh GDPR principle is sometimes left out, as it is a separate numbered point in Article 5 from the other principles delineated here, but we think it’s worth making clear.

As Article 5 says, “The controller shall be responsible for, and be able to demonstrate compliance with,” the principles of the GDPR.

So, not only do you have to follow the law of the GDPR, but you also have to be able to prove on demand that you are following the law of the GDPR on purpose. Documentation of your decision-making is important, as is having widely distributed internal policies and proof that you’ve trained people within your organization to understand them.

This principle is particularly relevant in combination with data minimization, purpose limitation, and storage limitation. If you have personal data on your servers, you should be able to demonstrate why it’s okay for it to be there.

The good news, however, is that the GDPR and the EU’s data protection principles in general allow wide latitude in how you comply with them. There’s no required technology or particular format that you need to use in documenting your accountability. Ultimately, if your organization is making a conscious effort and can document that effort, you should be good to go.

Case study: cookies, ePrivacy, and the GDPR principles

It’s fair to wonder, “Where do cookies fit into all of this?” As you look at how your web site uses cookies, you’ll see that these data privacy principles should help you figure out how to use them legally and make sure your organization is in compliance.

However, it’s important to understand that the GDPR works in tandem with the ePrivacy Directive, which governs the placement of electronic files onto personal devices. So, you have to think about two basic ideas:

  • Do I have permission to place this file on this person’s device?
  • If this file is then going to send me personal information in the future, do I have permission for that as well?

All of the cookie banners on the websites you visit are making sure the answer is “yes” to both of those questions.

As you may know, there are a variety of types of cookies that perform a variety of functions. It’s helpful to think of them in the following basic categories, though:

  • Session vs. Persistent: Is the cookie just on the device until the session ends, or does it stay on the device afterward for a period of time?
  • Necessary vs. Elective: Is the cookie vital for the operation of the web site or is it a “nice to have”?
  • First-party vs. Third-Party: Is the cookie coming from your organization or are you dropping the cookie on behalf of another organization?

The reason the banners pop up immediately and you have to make them go away is because many websites can’t function well at all without the use of necessary cookies. So the sites want you to accept cookies before doing anything else, allowing the site to function properly.

This makes sure you comply with the ePrivacy Directive: No placing of files before you’ve been given permission.

At the same time, man of these cookies are designed to provide information to your organization or a third party, so you need to also comply with the GDPR’s principles:

  • Lawfulness, fairness, and transparency: At the point of dropping the cookie, receive consent to collect the information (lawfulness), explain what you’ll be collecting and why (transparency), and provide an option for the data subject to continue on without giving you that permission (fairness). Also, make sure you explain their rights and provide contact information. 
  • Purpose limitation: Having a cookie on someone’s device could provide all kinds of juicy data for you. Make sure to only collect what you need to perform the task the cookie is meant to accomplish. If you need the cookie to make your shopping cart work, don’t also collect data with that cookie about other websites the data subject visits.
  • Data minimization: Make sure the cookie only collects the data necessary to perform the task at hand. If the shopping cart can be operated without collecting any data, that’s how much data should be collected: none. 
  • Accuracy: This shouldn’t be too much of a problem in a cookie environment, but sometimes with public wifi, etc., devices and cookies can become confused. Make sure you know which cookie is on which device. 
  • Storage limitation: Don’t leave the cookie there longer than it’s needed, and don’t keep the data the cookie sends back longer than is necessary. 
  • Integrity and confidentiality: If a cookie is collecting data, make sure you’re the only one that can access it on that data subject’s device. 
  • Accountability: Document your cookie policy, how you’re making sure you follow it, and how you know it’s working.

As you can see, complying with cookie law isn’t much different from complying with GDPR principles writ large. Follow the principles and you should find yourself in compliance and free of regulatory scrutiny. Ignore them at your peril.