What GDPR Actually Is (And Is Not)

The General Data Protection Regulation is a European Union law that has been in force since May 2018. It sets rules for how organizations collect, store, process, and share personal data about people in the EU.

What it is not: a bureaucratic checkbox exercise that only matters to compliance lawyers. GDPR has real teeth — enforcement has accelerated significantly in recent years — and its principles have influenced data protection laws in over 140 countries. If you handle data about people, understanding GDPR is simply part of operating responsibly in the current environment.

A few numbers that put the stakes in context. In 2024 alone, European data protection authorities issued over €2.9 billion in fines. Meta has faced fines exceeding €1.2 billion. LinkedIn, TikTok, and dozens of smaller organizations have paid penalties in the tens of millions. These are not outliers — enforcement is routine and growing.

Who GDPR Applies To

The scope of GDPR is broader than most people realize when they first encounter it.

GDPR applies to any organization that:

• Is established in the EU, regardless of where data processing occurs
• Is not established in the EU, but offers goods or services to people in the EU
• Is not established in the EU, but monitors the behavior of people in the EU

That last point catches a lot of companies off guard. If you run a website that uses analytics to track visitors in Germany, France, or anywhere else in the EU — you are in scope. Your physical location is irrelevant.

Two distinct roles carry obligations under GDPR:

Data Controller: The entity that determines why and how personal data is processed. A retailer collecting customer purchase history is the controller.

Data Processor: An entity that processes data on behalf of a controller. A cloud hosting provider, analytics vendor, or payroll processor are processors. Processors have direct obligations under GDPR now — not just controllers.

Relationship Between Controller and Processor

  [ Data Subject ]
         |
         | provides data to
         v
  [ Data Controller ]
         |
         | delegates processing to
         v
  [ Data Processor ]
         |
         | may further delegate to
         v
  [ Sub-Processor ]

Each link requires:
  - A documented legal basis
  - A Data Processing Agreement (DPA)
  - Appropriate technical safeguards

The Seven Principles

GDPR Article 5 establishes seven principles that all processing of personal data must follow. These are not aspirational guidelines — they are legal requirements.

1. Lawfulness, Fairness, and Transparency Processing must have a legal basis, must not deceive or harm individuals, and individuals must be informed about what happens with their data.

2. Purpose Limitation Data collected for one purpose cannot simply be repurposed. If you collect email addresses to send order confirmations, you cannot start using them for marketing without a separate legal basis.

3. Data Minimization Collect only what you actually need. Not what might be useful someday. Not everything the system is technically capable of capturing.

4. Accuracy Personal data must be accurate and kept up to date. Inaccurate data should be corrected or deleted without delay.

5. Storage Limitation Data cannot be kept indefinitely. Organizations must define retention periods and enforce them. This is one of the most commonly neglected obligations.

6. Integrity and Confidentiality Data must be protected against unauthorized access, accidental loss, destruction, or damage using appropriate technical and organizational measures.

7. Accountability The controller is responsible for compliance and must be able to demonstrate it. Documentation matters.

Legal Bases for Processing

Before processing personal data, you must identify a legal basis from the six available under Article 6. This is not optional — processing without a legal basis is unlawful.

A few points that trip organizations up:

Consent must be freely given, specific, and unambiguous. Pre-ticked boxes do not count. Consent bundled into terms of service does not count. Withdrawing consent must be as easy as giving it.

Legitimate interests is often misused as a catch-all. It requires a genuine balancing test — you cannot simply assert that your commercial interests are legitimate and move on.

Contract only covers processing strictly necessary to perform the contract. You cannot use it to justify processing that is merely convenient or useful.

Data Subject Rights

GDPR grants individuals eight rights over their personal data. Organizations must have processes in place to respond to these requests — typically within one month.

Right of Access (Article 15) Individuals can ask for confirmation that their data is being processed, and a copy of all personal data held about them. Responses must include details of purposes, categories of data, recipients, and retention periods.

Right to Rectification (Article 16) Individuals can request correction of inaccurate or incomplete data.

Right to Erasure (Article 17) Sometimes called the “right to be forgotten.” Individuals can request deletion of their data in specific circumstances — including where consent is withdrawn or where data is no longer necessary for its original purpose.

Right to Restriction (Article 18) Individuals can request that processing be paused — for example, while they contest the accuracy of data.

Right to Data Portability (Article 20) Individuals can request their data in a machine-readable format to transfer to another service.

Right to Object (Article 21) Individuals can object to processing based on legitimate interests or for direct marketing purposes.

Rights Related to Automated Decision-Making (Article 22) Individuals have the right not to be subject to decisions based solely on automated processing that significantly affect them — including profiling.

Right to Be Informed (Articles 13-14) The obligation to provide clear, accessible privacy information at the point of data collection.

Data Breach Notification

When a personal data breach occurs, GDPR sets a tight timeline.

Breach Response Timeline

Hour 0:   Breach discovered / suspected
          |
          v
Hour 1-4: Initial containment and internal escalation
          |
          v
Hour 24:  Internal incident documented
          Risk assessment underway
          |
          v
Hour 72:  DEADLINE — Notify supervisory authority
          if breach likely to result in risk
          to individuals' rights and freedoms
          |
          v
ASAP:     Notify affected individuals
          if breach likely to result in HIGH risk

The 72-hour clock starts when the organization becomes aware of the breach — not when it confirms the full scope. Organizations are expected to notify with the information available and supplement later.

Breaches that are unlikely to result in risk to individuals do not need to be reported to authorities, but they must still be documented internally.

Data Protection by Design and Default

Article 25 requires that data protection be considered from the earliest stages of system design, not added on afterward.

By design means that technical architecture choices should minimize privacy risk. Examples: encrypting data before storing it, using pseudonymous identifiers in analytics, building data deletion into the data model from day one.

By default means that the most privacy-friendly settings should be the default — not the most permissive. Users should have to actively choose to share more data, not actively choose to share less.

In practice, this standard affects product decisions as much as engineering ones. A social platform that defaults to public profiles fails this standard. A marketing system that pre-selects all consent categories fails it too.

Data Protection Impact Assessments

A DPIA is a structured risk assessment required before starting processing activities that are likely to result in high risk to individuals. High-risk activities include:

• Systematic profiling with significant effects
• Large-scale processing of sensitive data (health, biometric, criminal records)
• Systematic monitoring of publicly accessible areas
• Processing involving new technologies where the impact is unclear

A DPIA does not have to result in a decision not to proceed. Its purpose is to identify risks and implement measures to reduce them to an acceptable level. If residual risk remains high, you must consult your supervisory authority before proceeding.

Practical Compliance Building Blocks

Rather than listing abstract requirements, here is what a functioning GDPR compliance program actually looks like in operational terms.

Records of Processing Activities (ROPA) A document listing all processing activities, the legal basis for each, categories of data, retention periods, and technical measures. Required for organizations with more than 250 employees or processing high-risk data.

Privacy Notices Clear, plain-language statements explaining what data is collected, why, how long it is kept, and what rights individuals have. These must be provided at the point of collection.

Consent Management For processing based on consent, a system that records when consent was given, what was consented to, and enables withdrawal.

Data Processing Agreements Written contracts with every processor that specify the scope of processing, security requirements, breach notification obligations, and deletion requirements.

Data Subject Request Process A defined process for receiving, verifying, and responding to access, deletion, portability, and other requests within the required timeframe.

Breach Response Plan A documented procedure for identifying, containing, assessing, and notifying breaches within 72 hours.

GDPR in 2025: What Has Changed

GDPR itself has not changed since 2018, but how it is enforced and interpreted has evolved considerably.

Enforcement is broader and faster. Supervisory authorities across the EU now coordinate more effectively on cross-border cases through the European Data Protection Board. The “one-stop-shop” mechanism that allowed large companies to route complaints through a single friendly authority has tightened.

Consent for advertising is under sustained pressure. Meta’s “pay or consent” model was found to violate GDPR in 2024. The industry is grappling with what genuinely lawful consent for behavioral advertising looks like — which may be very little of current practice.

AI and profiling have become a focus area. Automated decision-making restrictions under Article 22 are getting more regulatory attention as AI tools that affect individuals proliferate. Transparency requirements for algorithmic decisions are being pushed harder.

Non-EU laws have converged toward GDPR standards. The UK GDPR post-Brexit, Brazil’s LGPD, India’s DPDP Act (2025 enforcement), and dozens of other national laws share GDPR’s core architecture. Compliance with GDPR is increasingly a foundation for compliance with other regimes rather than an isolated exercise.

Common GDPR Mistakes

Treating consent as the only legal basis. Many organizations default to consent for everything when another basis (contract, legitimate interests) would be more appropriate and more durable.

Neglecting retention schedules. Setting retention periods is only half the job — enforcing them through automated deletion is the other half, and it is frequently skipped.

Ignoring processors. Data sharing arrangements with vendors often lack proper Data Processing Agreements, and organizations have not assessed what those vendors do with the data.

Cookie banners that do not actually work. Many implementations technically show a consent banner but pre-select all categories or make rejection harder than acceptance. Regulators are paying attention to this.

Not training staff. GDPR obligations are organizational, not just technical. Employees who handle personal data need to understand basic requirements.

GDPR is seven years old now. The organizations that treated it as a one-time compliance project in 2018 and moved on are the ones receiving enforcement actions today. The ones that built privacy into how they operate — as a continuous practice rather than a project — are generally in a stronger position and tend to have better data practices overall.

The regulation is not going away. Its influence is expanding. Understanding it well enough to implement it properly is no longer optional for any organization that handles personal data at scale.