GDPR stands for General Data Protection Regulation, the European Union's data privacy law. It took effect on May 25, 2018, and it controls how organizations collect, use, store, and protect the personal data of people in the EU and the European Economic Area (EEA). It applies far beyond Europe's borders: if your business has even one EU customer, employee, or website visitor whose data you process, GDPR likely applies to you, regardless of where your company is based.
That last point trips up more businesses than any other part of the law. GDPR isn't a regional rule you can opt out of by not having a European office. It's triggered by whose data you handle, not where your company sits.
Why GDPR Exists
Before 2018, data protection across the EU was a patchwork. Each member state had its own national law, loosely based on a 1995 directive that predated smartphones, cloud computing, and targeted advertising. A company operating in five EU countries could face five different sets of rules for the same basic activity: collecting a customer's email address.
GDPR replaced that patchwork with one regulation that applies directly in every EU member state, with no need for each country to pass its own implementing law. In practice, that means if your business complies with GDPR, you're compliant with the national data protection law of every EU country at once. It also modernized the underlying framework for a world in which cookies, mobile apps, and biometric scanners have replaced paper forms as the main way data gets collected.
The regulation had three goals: give individuals real control over their own data, remove the compliance patchwork that made cross-border business harder than it needed to be, and back both of those with enforcement serious enough that companies would actually change how they operate.
Who Has to Comply With GDPR
GDPR uses three core roles. A data subject is the person whose data is being collected, such as a customer or website visitor. A controller is the organization that decides why and how that data gets processed, typically the business itself. A processor is any company that handles data on the controller's behalf, such as an email marketing vendor or a cloud hosting provider. Most SaaS companies are both: a controller for their own employee and business data, and a processor for the customer data they handle on their clients' behalf.
GDPR applies to your organization if any of the following is true:
- You have an establishment in the EU. A single EU-based employee, office, or long-term contractor is enough to trigger this, even if the data being processed belongs to people outside the EU.
- You offer goods or services to people in the EU. This doesn't require a sale. A free app, a newsletter signup, or a website with euro pricing or an EU-targeted language option can count as "offering," especially if you're actively marketing to that audience.
- You monitor the behavior of people in the EU. Website analytics, cookie-based ad targeting, or location tracking of EU visitors all count, even if your business has no physical presence in Europe at all.
There's no size exemption for the core obligations. A solo founder with 50 beta testers in Germany is just as subject to GDPR as a multinational retailer. The only size-based relief is a narrow one under Article 30: businesses with fewer than 250 employees can skip some record-keeping paperwork, but only if their processing is occasional, poses low risk, and never touches sensitive categories of data. Most software companies fail that test simply by running continuous analytics or CRM systems, so this exemption applies to far fewer businesses than its wording suggests.
What Counts as Personal Data
Article 4 of GDPR defines personal data as any information relating to an identified or identifiable natural person. The person doesn't need to be named outright. If a piece of data could reasonably be linked back to a specific individual, directly or indirectly, it counts.
That covers more than most people expect. Obvious examples include a name, home address, phone number, or national ID number. Less obvious examples include an IP address, a cookie ID, a device advertising ID, and even purchase history that, combined with other data points, could single someone out. A useful comparison: an email address like jane.smith@company.com is personal data because it identifies a specific person, while a generic inbox like info@company.com generally is not, because no individual is identifiable from it.
Some categories get extra protection because misuse carries higher risk. Article 9 calls these special categories: health data, biometric data, genetic data, racial or ethnic origin, political opinions, religious beliefs, trade union membership, and data about sex life or sexual orientation. Criminal conviction data gets similar treatment under Article 10. Processing any of these generally requires explicit consent or a narrow legal exception, plus stronger security controls.
Two things fall outside the definition entirely. Data about a company, rather than a person, isn't personal data (a company registration number isn't covered). And data that's been irreversibly anonymized, so there's no realistic way to trace it back to a person, isn't personal data either. Pseudonymized data, where identifying details are replaced with a code that can still be reversed, is a different story: it remains personal data, because the link to the individual still technically exists.
The Core Principles Behind Every GDPR Obligation
Article 5 sets out seven principles that everything else in the regulation builds on:
- Lawfulness, fairness, and transparency. You need a valid legal reason to process data, and people need to understand how their data is being used.
- Purpose limitation. Data collected for one stated purpose can't quietly be repurposed for another. If you collect an email for order confirmations, using it later for a marketing newsletter needs its own legal basis.
- Data minimization. Collect only what you actually need. A signup form asking for a phone number "just in case" is already out of step with this principle.
- Accuracy. Data has to be correct and kept current, with a process for fixing it when it isn't.
- Storage limitation. Data can't be kept indefinitely. It should be deleted or anonymized once it's no longer needed for its original purpose.
- Integrity and confidentiality. Data has to be protected with security measures appropriate to the risk, from encryption to access controls.
- Accountability. It's not enough to comply. You have to be able to demonstrate compliance, through documentation like records of processing activities and impact assessments.
The Practical Obligations This Creates
Turning those principles into daily practice means putting several concrete things in place.
A lawful basis for every processing activity. GDPR recognizes six legal bases, and every processing activity needs at least one:
| Lawful basis | When it applies |
|---|---|
| Consent | The person has freely, specifically, and clearly agreed, and can withdraw as easily as they agreed |
| Contract | Processing is necessary to perform a contract with the person, or to take steps before entering one |
| Legal obligation | The law requires it, independent of any agreement with the person |
| Vital interests | Necessary to protect someone's life, typically in emergencies |
| Public task | Necessary for a task carried out in the public interest or under official authority |
| Legitimate interests | A genuine business interest that doesn't override the person's own rights and expectations |
Consent is the one most businesses reach for by default, but it isn't always the right fit. Consent has to be freely given, specific, and as easy to withdraw as it was to give, which is why pre-ticked checkboxes don't count. A compliant cookie consent banner is usually where this obligation becomes visible to an actual website visitor for the first time.
Clear privacy notices. People need to be told, at the point their data is collected, who's collecting it, why, how long it will be kept, and what rights they have over it.
A Data Protection Officer, for some organizations. Article 37 requires a DPO if you're a public authority, if your core activity involves large-scale systematic monitoring of people, or if your core activity involves large-scale processing of special-category or criminal-offense data. Outside those cases, appointing a DPO is optional, though many businesses do it anyway once their data operations grow complex enough to need dedicated ownership.
An EU representative, for some non-EU businesses. If your company has no EU establishment but is subject to GDPR because you target or monitor EU residents, Article 27 requires appointing a representative based in the EU as a point of contact for regulators and individuals. There's an exemption for processing that's occasional, low-risk, and doesn't touch special-category data, but most businesses running any kind of ongoing EU-facing operation don't qualify for it.
Breach notification within 72 hours. If personal data is exposed through a security incident, the controller must notify the relevant data protection authority within 72 hours of becoming aware of it. If the breach creates a high risk to the people affected, those individuals need to be told directly too. The obligation runs the other direction as well: if a processor (say, a vendor handling data on your behalf) suffers a breach, it has to notify the controller it works for without undue delay, so the controller can meet its own 72-hour clock.
A Data Protection Impact Assessment, before high-risk processing starts. Article 35 requires a DPIA whenever a new processing activity is likely to pose a real risk to people's rights, such as large-scale profiling, systematic monitoring of a public space, or processing special-category data at scale. The assessment has to identify the specific risk, weigh it against the purpose, and document what's being done to reduce it, and it has to happen before the processing starts, not as a retroactive justification after something goes wrong.
Data Subject Rights
GDPR gives individuals a set of rights over their own data, and businesses need working processes to honor them, not just a policy that mentions them. The main rights are:
- To be informed. The right to be told, in clear language, who's collecting your data, why, and who it's shared with, before or at the point of collection.
- Access. The right to confirm whether your data is being processed and get a copy of it.
- Rectification. The right to have inaccurate data corrected.
- Erasure (the "right to be forgotten"). The right to have data deleted once it's no longer needed, consent is withdrawn, or processing was unlawful, subject to some exceptions like legal recordkeeping requirements.
- Restriction. The right to limit how data is used while a dispute about it is resolved.
- Portability. The right to receive data in a structured, machine-readable format and move it to another provider.
- Objection. The right to object to certain processing, including direct marketing, where the objection is absolute and processing must stop immediately.
- Protection from purely automated decisions. The right not to be subject to a decision based solely on automated processing, including profiling, when it has legal or similarly significant effects.
Most of these come with a one-month response deadline, extendable to three months for complex requests. In practice, this means having an intake process, a way to verify the requester's identity, and a way to search across every system that might hold their data, not just the obvious ones.
GDPR Fines and Enforcement
GDPR set the benchmark for how large a data protection fine can be. Article 83 splits penalties into two tiers:
| Tier | Maximum fine | Example violations |
|---|---|---|
| Tier 1 | EUR10 million or 2% of global annual turnover, whichever is higher | Inadequate record-keeping, failing to appoint a required DPO, late breach reporting |
| Tier 2 | EUR20 million or 4% of global annual turnover, whichever is higher | Processing without a lawful basis, ignoring data subject rights, violating a core Article 5 principle |
The "whichever is higher" detail matters. For a small business, the flat euro figure is usually the operative one. For a large multinational, 4% of global turnover can dwarf the euro cap entirely, which is exactly the point: the fine scales with the company's size and its capacity to have done better.
Fines aren't the only consequence. Regulators can order corrective action, temporarily or permanently ban certain processing activities, and require mandatory audits. For companies that sell into enterprise or EU markets, an unresolved GDPR finding can also stall deals, since procurement teams increasingly ask for evidence of compliance before signing. This is also where GDPR intersects most directly with marketing: campaigns built on data collected without a valid lawful basis are one of the more common sources of enforcement action, a topic covered in more depth in this project's guide to GDPR and marketing.
Quick GDPR Compliance Checklist
Understanding what GDPR requires is the first step. Turning it into a working program means having a real answer for each of these:
- Know what personal data you collect and where it lives.
- Identify a lawful basis for each processing activity.
- Publish privacy notices that actually say what you do with data.
- Build a process for data subject rights requests.
- Have a breach response plan that meets the 72-hour clock.
- Decide whether you need a DPO, and run a DPIA for high-risk processing.
This is the short version. For the full step-by-step checklist, see this project's GDPR compliance guide and checklist.
Who Enforces GDPR
Each EU member state has its own data protection authority, and GDPR's one-stop-shop mechanism lets a business dealing with regulators in multiple countries work primarily through a single lead authority, usually wherever its main EU establishment is based. That coordination process is getting more standardized: a new EU regulation, (EU) 2025/2518, entered into force on January 1, 2026 to harmonize how cross-border complaints are handled and to introduce binding investigation deadlines, applying to investigations and complaints opened from April 2, 2027 onward.
How GDPR Compares to Other Privacy Laws
GDPR isn't the only major privacy law businesses have to think about. The California Consumer Privacy Act (CCPA) and its state-level successors share some DNA with GDPR, like giving individuals rights over their data and requiring transparency about data practices, but the specifics diverge enough that complying with one doesn't automatically satisfy the other. If your business has both EU and California users, for instance, you need to map each law's requirements separately rather than assume one compliance program covers both. See this project's comparison of CCPA and GDPR for where the two actually diverge.
Frequently Asked Questions
Does GDPR apply outside Europe?
Yes. GDPR applies to any organization, regardless of where it's based, if it offers goods or services to people in the EU or monitors their behavior.
Do small businesses need to comply with GDPR?
Yes, if they process the personal data of people in the EU. There's no general size exemption for core obligations like having a lawful basis, providing privacy notices, and honoring data subject rights.
What happens if a business violates GDPR?
Financial penalties of up to EUR20 million or 4% of global annual turnover for the most serious violations, plus possible corrective orders, processing bans, and mandatory audits. See the fines section above for the full two-tier structure.
Does every business need a Data Protection Officer?
No. A DPO is mandatory only for public authorities and for organizations whose core activity involves large-scale systematic monitoring or large-scale processing of special-category data. Many other businesses appoint one voluntarily as their data operations grow.
Does every business need to run a DPIA?
No. A DPIA is only required before starting a specific processing activity that's likely to pose a real risk to people's rights, such as large-scale profiling or processing sensitive data at scale. Most routine, low-risk processing never triggers one.
Building GDPR Compliance Into How You Operate
Reading through GDPR's obligations makes one thing clear: this isn't a document you file away after a single review. Data flows change as your product changes, new vendors get added, and marketing tactics evolve, which means lawful bases, privacy notices, and consent records all need to keep pace. Businesses that treat GDPR as a continuous practice, revisited as the business changes, tend to avoid the gap between what their privacy policy claims and what their systems actually do, which is where most enforcement action starts. A broader look at cookie compliance and how it fits into the wider GDPR picture is a reasonable next stop if consent is the piece you're least confident about, and the full breakdown of GDPR fines and penalties is worth reading before assuming a gap is low-risk.
Cookie and tracking consent is usually the most visible piece of this, since it's the first GDPR-related interaction most website visitors ever see. Getting it right matters for both compliance and user trust, and it's worth treating as its own project rather than an afterthought. Secure Privacy's consent management platform handles the cookie-banner and consent-logging side of GDPR compliance, along with DSAR request workflows and coverage for more than 55 other privacy laws beyond GDPR, for businesses that want that piece handled without building it themselves.
