What Is the GDPR? A Practical Guide for Business Contracts

Everyone who works with contracts has seen it. A deal is moving nicely, and then someone mentions the GDPR or that data privacy wording needs to be added in the contract. Suddenly there are extra documents like DPAs, including new questions and delays. Most people on the deal have never had a plain explanation of what this law actually is.

So, what is the GDPR, why does it matter for business contracts and how can you prevent these issues? This practical guide gives sales, procurement, founders and lawyers the essential GDPR basics, plus the relatively simple steps that can keep privacy questions from delaying signature. It is written for an international audience, reflecting the contracts I work on between European companies and businesses in the US, Middle-East and Asia. The next articles in this series go deeper into DPAs and SCCs.

The good news is that many of the problems are relatively easy to prevent. In this article we will do more than explain the GDPR. We cover the basics you need to know and the practical steps to take in this article ‘What Is the GDPR? A Practical Guide for Business Contracts’.

What Is the GDPR? The Short Version

In short, here are the six points to remember:

• The GDPR is the EU’s general rulebook for personal data. One regulation, every EU country, across sectors. The UK has kept its own very similar version.
• The GDPR can also bind companies outside the EU when they offer goods or services to people in the EU, or monitor their behaviour. The UK GDPR has a similar reach.
• Personal data is much broader than you may think. A work email address counts. An IP address counts. Even harmless-looking pieces of information count once they can be combined to point to one person.
• For contracts, the key concepts are personal data, processing, and the two roles, controller and processor. Understand these and every privacy document in your deal starts making sense.
• Fines can reach 20 million euros or 4 percent of worldwide turnover. But the everyday reason to care is simpler. Deals do not sign until the privacy paperwork is right.
• The practical fix: identify the data and the parties’ roles early, use approved DPA and SCC documents, and complete the required information before final negotiations. Most avoidable GDPR delays are process problems, and process problems can be fixed.

GDPR for Business: Key Terms for Contracts

You will run into these terms in almost every deal. Here is what they mean, without the legal language.

• GDPR: the General Data Protection Regulation. The EU’s law on personal data, in force since 2018.
• UK GDPR: the UK’s own version, kept after Brexit. Very similar rules and principles.
• Personal data: any information about an identified or identifiable person. Much broader than most people expect.
• Data subject: the person the data is about. An employee, a customer, a user.
• Processing: almost anything you do with personal data. Collecting, storing, viewing, sharing, deleting.
• Controller: the party that decides why and how personal data is used. Usually the customer in a vendor deal.
• Processor: the party that handles the data on the controller’s instructions. Usually the vendor.
• Privacy notice: the public explanation a controller must give to the people whose data it uses. Sometimes called a privacy statement or privacy policy.
• Lawful basis: the legal reason you are allowed to process personal data at all. The law lists six.

What Is the GDPR and When Does It Apply?

The GDPR is the General Data Protection Regulation. It is a European Union regulation, in force since 2018, and the word regulation matters. An EU regulation applies directly in every EU country. No country needs to pass its own version first. Individual countries can add specific rules on certain topics, but the GDPR provides the shared framework across the EU.

A side note on geography: the EU GDPR also extends across the European Economic Area, which includes Iceland, Liechtenstein and Norway. After Brexit, the UK kept its own very similar version, the UK GDPR. So in this article, references to Europe generally mean the EEA and the UK unless stated otherwise.

Two more things make the GDPR different from what many US readers are used to.

First, it is one cross-sector rulebook. The US regulates privacy largely sector by sector: one law for health data, another for financial data, plus a growing patchwork of state laws. The GDPR applies across industries. There is no general “we are not a regulated industry” exit.

When Does the GDPR Apply Outside the EU?

The GDPR can apply to organisations outside the EU when they offer goods or services to people in the EU, or monitor their behaviour there. No European office is required. Mere website accessibility is not enough, but actively targeting EU customers can bring a company within scope. The UK GDPR uses a similar test for people in the UK.

This is why the GDPR matters even to companies that see themselves as purely American. A US company that targets European customers or monitors people in Europe may have to comply. That is often the moment the GDPR lands on its contracts.

And the law has teeth. Fines can reach 20 million euros or 4 percent of a company’s worldwide annual turnover, whichever is higher. But in daily practice the pressure is more direct: European counterparties simply will not sign until the privacy side of the deal is in order.

Want the source? Articles 1 to 3 GDPR cover what the law is and where it applies.

What is Personal Data Under the GDPR?

Here is the single biggest misunderstanding we see, especially from US teams.

Personal data is any information about an identified or identifiable person. Not just sensitive records. Not just consumer data. Any information about a person.

10 Everyday Examples of Personal Data Under the GDPR

These examples appear in ordinary business tools and contracts more often than most teams expect:

1. Work email addresses, such as jane.smith@company.com.
2. Names and job titles in contact lists and email signatures.
3. IP addresses and device IDs in website logs and app telemetry.
4. User accounts and login records, including account IDs and access history.
5. Support tickets and chat messages tied to a customer or user.
6. Meeting recordings and transcripts containing voices, faces or written conversations.
7. CVs and employee records, including applications, payroll information and reviews.
8. Customer and supplier contacts, including names, roles and direct numbers.
9. Location and product-usage data showing where and how a service is used.
10. Details that identify someone when combined, such as a postcode, date of birth and job title.

Here is the part almost everyone misses: information can also become personal data in combination. One piece on its own may point to nobody. A postcode alone covers many people. But a postcode plus a date of birth plus a job title can point to exactly one person. Once pieces of information can be put together to identify someone, they are personal data. So the question is never “is this one field sensitive?” but “could this information, combined, point to a person?”

What matters is whether someone, in practice, could use that combination to single out one specific individual. Even three ordinary-looking fields, on their own harmless, can together point to one person.

One more thing: it does not matter how the data reaches you. If you can see it, if you receive it, if it simply sits on your servers, you are dealing with personal data and the rules apply to you.

So the honest rule of thumb is this: if you think your deal does not touch personal data, you are almost certainly wrong.

Want the source? Article 4(1) GDPR defines personal data.

What Does Processing Mean Under the GDPR?

Processing is one of the most important concepts to understand when you deal with data privacy, globally, and especially under the GDPR. The reason is simple: every duty in this law attaches to processing. Who is responsible, who must protect the data, who must answer when something goes wrong. It all starts with the question of who processes what. When we get to responsibilities in the next articles, this is the concept everything builds on.

The definition is deliberately wide. Processing means almost anything you do with personal data, and the law itself lists the examples: collecting it, recording it, storing it, retrieving it, using it, sharing it, deleting it.

Yes, storing is on the list. This matters in deals because of one common objection: “we only store the data, we never look at it.” Under the GDPR, storage is processing. A vendor that only hosts files, and never opens a single one, is still processing personal data, and the rules still apply to it.

Put the two broad concepts together and you see why the GDPR reaches into almost every contract. Almost everything is personal data, and almost everything you do with it is processing.

Want the source? Article 4(2) GDPR defines processing, storage included.

GDPR Controller vs Processor: Who Decides and Who Executes?

Two quick questions.

Is Netflix the controller or the processor of your viewing history? Controller. You never instructed Netflix to do anything. Netflix decides what to collect, how to use it, and what to recommend you next.

Now your salary. Your employer runs payroll through an external payroll provider. Who is responsible for your salary data? Your employer decides what you earn, when you are paid, and how long the records are kept. The payroll company just executes. Your employer is the controller. The payroll provider is the processor. The same goes for Zoom storing your company’s meeting recordings: your company decided to record and how long to keep them, Zoom executes.

That is the whole concept, and it always comes down to one question: who decides? The party that decides why and how data is used is the controller. The party that executes on instructions is the processor.

Can the Same Company Be Both Controller and Processor?

Yes. That is the reason even people who work with this daily still find it hard. Take Gmail. Your private Gmail account: Google decides how the service works, so Google is the controller. Your work email on Google Workspace: your employer decides, Google executes, so Google is the processor for that service. Same company, similar product, different role. The role depends on who decides the purposes and means of the specific processing.

And the role matters, because under the GDPR the roles decide who is responsible for what. For example:

• Who must answer when a person asks about their data.
• Which company is responsible to report a data breach.
• Who is on the hook when something goes wrong. Every privacy document in your deal is built on this split.

What Do the GDPR Roles Mean in a Business Contract?

Think of a company, Acme Inc. They hold information about its employees and its customers. Acme decides to buy software:

• Salesforce for its customer data,
• Microsoft 365 for email, and
• an approved business version of ChatGPT for its teams.

Acme decides why these tools are used and which data goes in. That makes Acme the controller. The software providers handle Acme’s data to deliver their service, as agreed in the contract. That makes them processors for that processing.

That is the whole idea. The controller decides. The processor executes, on the controller’s instructions.

One warning, even in a basics article: the label in the contract does not decide the role. What a company actually does decides it. A vendor that starts using customer data for its own purposes, for example to train its AI models, is no longer just a processor for that activity. Remember this one. It becomes important in the next articles, especially where AI is involved.

And one side note: most deals look like the Acme example, one controller and one processor. Sometimes two companies each decide for themselves what they do with shared data. Then you have two controllers, a controller-to-controller relationship, with different paperwork. We will not go into that here.

Want the source? Articles 4(7) and 4(8) GDPR define controller and processor. The European Data Protection Board also provides a practical explanation.

GDPR Privacy Notices and DPAs: What Is the Difference?

Why did you never sign a DPA with Netflix?

Here is a question the roles immediately answer. You use Netflix, Spotify, maybe the free version of ChatGPT. You never signed a data processing agreement with any of them. Why not?

Because a DPA belongs to the controller-processor relationship. It is the contract a company signs when it asks another company to process data on its behalf. As a consumer, you are not instructing anyone. Netflix is the controller, and you are simply the person the data is about. No controller-processor relationship, so no DPA.

What you get instead is the privacy notice. The privacy notice is the controller’s duty: every controller must explain to the people whose data it uses what it collects, why, for how long, and who it shares it with. That is why every consumer service has one, and why it is written to you.

And this duty has teeth. The Dutch privacy regulator fined Netflix 4.75 million euros because its privacy statement did not explain clearly enough what it did with customer data. Netflix objected to the fine, but the message to every controller is the same: the notice is not decoration.

A processor works differently. It does not owe you a notice for the data it handles on behalf of its customer. Its duties run to the controller, through a contract. That contract is the DPA. (The vendor is still a controller for its own things, its website, its billing, its own staff, and has a privacy notice for those.)

So here is the simple map. Consumer products: the company is the controller, you get a privacy notice, and there is no DPA. Business tools: the vendor is the processor, the two companies sign a DPA, and your employer owes you the notice. And one handy trick: want to know a company’s role? Open its privacy notice. The controller must name itself there. Netflix’s names Netflix, and for European customers, its Dutch entity in Amsterdam.

Want the source? Articles 12 to 14 GDPR cover privacy notices. Article 28 covers the DPA. Both come back in the next article in this series.

What Is a Lawful Basis Under the GDPR?

One more foundation, and then you have the full picture.

Under the GDPR, you cannot process personal data just because you want to. You need a legal reason, a lawful basis. The law lists six. Three matter in daily business:

• Contract: you may use the data you need to deliver what was agreed. Order something at Amazon, and Amazon may use your name and address to deliver your package. Without that data, no delivery.
• Legitimate interests: you may also use data for closely related things a customer would reasonably expect. Amazon checking your order for fraud, for example. What this basis does not allow is going much further than what people would expect. It is the everyday workhorse in B2B, and also the most misused.
• Consent: the person agreed. Consent feels like the safe choice, especially to US readers. In business settings it is usually the weakest one, because it can be withdrawn at any time.

Now the point for commercial teams. When you are selling, your customer will assume there is a proper legal basis behind everything your product does with data, so make sure that question has been discussed with your legal or data privacy team before it comes up in the deal. When you are buying, the homework is yours: a vendor cannot supply your lawful basis for you. Either way, this is a question for legal early in the process, not after signature.

Want the source? Article 6 GDPR lists the six lawful bases.

What Does the GDPR Mean for Business Contracts?

Now the pieces come together.

GDPR Compliance for Business Contracts: Five Practical Steps

You do not need to turn every salesperson, procurement manager or founder into a privacy specialist. A small number of repeatable steps will prevent many of the problems that slow deals down:

1. Identify the personal data. Ask what information the service collects, stores, accesses or generates. Do this before someone assumes that a deal has no privacy impact.
2. Confirm the parties’ real roles. Decide who determines why and how the data is used, and who acts on instructions. Do not rely only on the labels in the contract.
3. Raise the paperwork early. If a DPA or international transfer mechanism may be needed, put it on the deal checklist at the start rather than introducing it just before signature.
4. Use approved documents and complete the details. Standard DPA and SCC documents solve only half the problem. The annexes still need an accurate description of the data, purpose, duration, security measures and sub-processors.
5. Create a clear route for exceptions. Let the commercial team handle recurring questions with approved guidance, while legal or privacy specialists focus on unusual data uses, high-risk information and non-standard transfers.

These steps will not remove every privacy question, but they take away much of the avoidable friction. The goal is to help commercial teams recognise the recurring issues, follow a workable process and know when specialist advice is actually needed.

The DPA and SCC Basics

Because personal data is defined broadly and many services process it, European law requires specific privacy paperwork in many commercial deals. Two documents appear particularly often:

• The DPA, the Data Processing Agreement: the contract Article 28 GDPR requires when a processor handles personal data on a controller’s behalf.
• The SCCs, the Standard Contractual Clauses: standard clauses that can provide a legal safeguard for sending personal data outside the EEA, for example to a US parent company or US cloud provider, when the applicable requirements are met.

These two documents are where deals slow down in practice, and they are each worth their own plain explanation. That is exactly what the next two articles in this series do: what a DPA is and why every deal has one, and what SCCs are and why you should never try to negotiate them.

This was the very basics, on purpose. If you understand personal data, processing, controller versus processor and lawful basis, the rest of this series will feel much easier.

At AMST Legal we help US and European companies get this right: understanding what the GDPR requires in their contracts, and building templates and processes so the privacy paperwork stops delaying deals. If the GDPR keeps showing up in your contracts and nobody has ever explained it properly, this series is for you, and we are happy to help with the rest.

Frequently Asked Questions: What Is the GDPR and How Does It Affect Business?

What Is the GDPR in Simple Terms?

The GDPR is the EU’s general law on how organisations may collect, use, store, share and delete personal data. It also gives individuals rights over their data and assigns responsibilities to controllers and processors.

Does the GDPR Apply to US Companies?

It can. The GDPR may apply to a US company that offers goods or services to people in the EU or monitors their behaviour there. A company does not always need an EU office to fall within its scope.

What Counts as Personal Data Under the GDPR?

Personal data is any information relating to an identified or identifiable person. It includes obvious details such as names and email addresses, but can also include IP addresses, user IDs, support tickets and information that identifies someone when combined.

What Is the Difference Between a Controller and a Processor?

The controller decides why and how personal data is used. The processor handles that data on the controller’s instructions. The real activity determines the role, not the label in the contract.

When Is a DPA Required Under the GDPR?

A DPA is required when a controller appoints a processor to process personal data on its behalf. Article 28 GDPR requires that relationship to be governed by a written contract containing specific terms.

Why Does the GDPR Matter for Business Contracts?

The GDPR determines which privacy documents, security obligations, data-use restrictions and international transfer terms a deal may need. If those points are raised late or described incorrectly, they can delay signature and create compliance risk.