Privacy Laws for Engineers: GDPR, CCPA & What You Build

For most of computing history, “what data do we keep, and why?” was a question you could shrug off and leave to the legal team. That era is over.

In 2018 the EU’s GDPR created one strict privacy law. By 2025 there were roughly 157 active data-protection regulations worldwide, up from 128 just three years earlier. These rules now reach straight into your codebase: they shape your database schemas, decide what you may write into a log, force you to build a working “delete my account” pipeline, and even dictate which country your servers can sit in.

This is not a law lecture. It is a practical guide to what you, the engineer, actually have to build.

Why this matters

Privacy used to be paperwork. Now it is architecture.

When a regulator asks you to delete one person’s data, you have to find it first, across every microservice, cache, backup, and third-party tool. When a breach hits, you may have just 72 hours to report it. When you ship data to a US analytics vendor, you might be breaking the law without realizing it.

Get this wrong and the bill is real. GDPR fines reach €20M or 4% of global annual revenue, whichever is bigger. The EU AI Act goes up to 7%. And that sits on top of the average data breach, which IBM pegs at $4.44M globally and over $10M in the US.

The good news: most of compliance is just good engineering done on purpose. Let’s make it concrete.

First, two words you’ll use constantly

PII means personally identifiable information - any data that points to a specific human: name, email, IP address, device ID, location, purchase history. Personal data is the broader term GDPR uses for the same idea.

Privacy law is, at its core, a set of rules about how you treat PII. Keep that anchor in mind and the rest falls into place.

Privacy and security are not the same thing

Engineers mix these up constantly. They answer two different questions.

• Security asks: is the data protected from people who shouldn’t see it? It’s measured by the CIA triad - Confidentiality, Integrity, and Availability.
• Privacy asks: should you have this data at all, and are you respecting the person’s rights over it? Collect only what’s justified, use it only for the stated reason, delete it when asked.

An analogy. Security is locking the filing cabinet so burglars can’t get in. Privacy is only putting files in the cabinet that you’re allowed to keep, and shredding them when you’re done.

You can have a perfectly locked cabinet (great security) stuffed with files you had no right to collect (terrible privacy). The flip side is also true: a data breach is by definition a privacy failure. So you can’t have privacy without security.

GDPR: the template everyone copies

The General Data Protection Regulation has applied across the EU and EEA since May 2018. The rest of the world keeps imitating it, a phenomenon called the “Brussels Effect.” Learn GDPR’s core ideas and most other privacy laws will feel like reskins.

Here are the concepts that change what you build.

Controller vs. processor

A controller decides why and how personal data gets processed. That’s usually the company collecting it, and it carries most of the legal responsibility.

A processor only acts on the controller’s instructions: your cloud host, your email vendor, your analytics tool.

Think of it like a move. The controller is the person who hires the moving company; the processor is the movers, who only do what they’re told. Here’s the catch: if a “processor” starts deciding on its own what the data is for, it legally becomes a controller. Every controller-to-processor relationship needs a written contract called a DPA (Data Processing Agreement).

You need a lawful basis for everything

You cannot collect data “just because.” For every processing activity, GDPR requires exactly one of six justifications: consent, contract (you need the data to deliver the service), legal obligation, vital interests, public task, or legitimate interests.

A common trap is reaching for consent as the default for everything. Valid consent must be freely given, specific, unambiguous, and as easy to withdraw as it was to give. Pre-ticked boxes, bundled “agree to everything” buttons, and forced consent are all illegal. Often contract or legitimate interests is the cleaner, more honest basis anyway.

The DSAR: where privacy becomes an architecture problem

A DSAR (Data Subject Access Request) is when a person exercises their rights. They can ask you to:

• tell them what you hold (access),
• fix it (rectification),
• delete it (the right to be forgotten),
• export it in a portable format (portability),
• or stop processing it.

You must respond, for free, within about a month.

This is the single biggest reason privacy turns into an engineering challenge. To delete or export “all of one person’s data,” you first have to find it, across every microservice, cache, log file, backup, analytics platform, and outside vendor. If you scattered PII everywhere with no plan, you literally cannot comply, no matter how much you want to.

The 72-hour breach clock

When a controller becomes “aware” of a breach that’s likely to harm people’s rights, it must notify the supervisory authority within 72 hours, and tell affected individuals too if the risk is high. A processor must alert its controller “without undue delay.”

Seventy-two hours is brutal. You can only hit it if detection, logging, on-call rotations, and a rehearsed incident runbook already exist before the breach. You cannot improvise this at 2 a.m.

Privacy by design, minimization, and DPIAs

Three more ideas you’ll build around:

• Data minimization: collect only what you need, keep it only as long as you need it.
• Privacy by design: make privacy the default, baked into schemas and settings, not bolted on later.
• DPIA (Data Protection Impact Assessment): a documented risk assessment required before high-risk processing, like large-scale sensitive data, systematic monitoring, or profiling. It’s privacy’s version of a design review.

The fines tell a story

GDPR fines have topped €7.1B since 2018. The headline cases rhyme:

• Meta - €1.2B (2023): illegal EU-to-US data transfers. The record.
• TikTok - €530M (2025): sending EEA user data to China without adequate safeguards.
• LinkedIn - €310M (2024): behavioral advertising with no valid lawful basis.
• Uber - €290M (2024): transferring driver data to the US without safeguards.
• Meta - €251M (2024): the 2018 “View As” breach that exposed around 29M accounts.

Notice the pattern: the biggest fines are almost always about (a) cross-border transfers or (b) ad-tech and profiling without a lawful basis. Remember those two and you’ve internalized most of the risk.

The US is a patchwork, not one law

There’s no single federal US privacy law. Instead, as of 2025–26, about 20 states have their own comprehensive consumer-privacy laws. They share a baseline: a privacy notice, the right to opt out of “sale or sharing,” extra rules for sensitive data, and access and delete rights.

California leads. The CCPA, strengthened by the CPRA, gives people the right to know, delete, correct, opt out of “sale or sharing,” and limit how their sensitive info is used. It’s enforced by a dedicated agency, the CPPA.

Recent enforcement shows exactly what regulators hate:

• Honda - $632,500 (2025): made opting out too hard and used lopsided cookie-banner choices.
• Healthline - $1.55M (2025): leaked article titles that revealed readers’ health conditions to ad partners.
• Tractor Supply - $1.35M (2025): the largest CPPA fine to date.

The lessons repeat: regulators target dark patterns (deceptive UI that nudges you away from privacy), broken “Do Not Sell” links, ignoring the Global Privacy Control (an automatic browser opt-out signal you’re supposed to honor), and missing data terms in vendor contracts.

Sector-specific laws you can’t ignore

Some data is special and gets its own rulebook.

HIPAA - US health information

Covers protected health information (PHI). A major Security Rule overhaul proposed in 2025 would make safeguards mandatory: encryption of health data at rest and in transit, MFA, annual penetration testing, network segmentation, and fast system restoration. It applies to vendors (“business associates”), not just hospitals. Treat it as imminent and tightening.

PCI DSS - payment-card data

Technically an industry standard, not a law, but mandatory the moment you touch card data. Newer web rules require you to inventory and integrity-check every script on payment pages (anti-skimming) and detect tampering. The core rule never changed:

Never store the CVV. Encrypt the PAN (card number).

Storing the CVV “to make recharging easier” is a flat violation, and a classic real-world bug. Tokenize through your payment processor instead, so raw card data never reaches your database.

COPPA - children under 13

Recent amendments expanded “personal information” to include biometrics like face and voice templates, and require separate opt-in parental consent before sharing kids’ data with third parties or advertisers.

The GDPR-likes are spreading everywhere

Thanks to the Brussels Effect, GDPR-shaped laws now circle the globe. If you have users abroad, assume a privacy law applies to you.

• Brazil - LGPD: very GDPR-like.
• China - PIPL: GDPR-style consent plus strict data-localization. Getting data out of China is genuinely hard.
• UK - UK GDPR: the post-Brexit clone.
• India - DPDP Act: rolling out in phases, with penalties up to ₹250 crore (around $30M) and a new Data Protection Board.
• Canada - PIPEDA, and dozens more.

The myth to kill here: “We’re US-only, so GDPR doesn’t apply to us.” GDPR applies based on who you serve, not where you’re incorporated. If EU residents can sign up, you’re in scope.

Cross-border transfers: a genuinely hard engineering topic

This is where most of the giant fines come from, so it deserves real attention.

GDPR restricts sending personal data outside the EEA unless the destination offers “adequate” protection. There are three legal paths:

1. Adequacy decisions - the EU declares an entire country or scheme safe (for example, the UK, or US firms certified under the Data Privacy Framework).
2. SCCs (Standard Contractual Clauses) - EU-approved contract templates signed between the data exporter and importer. The most common tool.
3. BCRs (Binding Corporate Rules) - internal rules approved for transfers within one corporate group.

If none of these apply, the transfer is simply illegal. That’s what cost Meta €1.2B.

One nuance worth knowing: the EU–US Data Privacy Framework is today’s bridge for US transfers, but it’s under live legal threat (a “Schrems III” challenge could strike it down, just as its two predecessors were struck down). Treat transatlantic transfers as perpetually fragile and design so you could switch paths if you had to.

Two terms people confuse:

• Data residency: data is stored or processed in a given region, but transfers are allowed with safeguards.
• Data localization: stricter. Data may never leave the country, including backups and even support access.

The trap that catches good teams. You pin your main database to an EU region and feel safe. Meanwhile your logs, error tracker, and analytics quietly ship PII to a US-hosted SaaS. The data still crossed the border. Audit every outbound data flow, not just the obvious one.

The EU AI Act: the next wave

The EU AI Act, in force since August 2024, is the first big risk-tiered AI law. It sorts AI systems into four tiers:

• Unacceptable (banned): social scoring, manipulative AI, most real-time public biometric ID.
• High-risk: recruitment, credit scoring, education, law enforcement. Requires risk management, data governance, human oversight, and logging.
• Limited-risk: chatbots and AI-generated content. Requires transparency - tell users it’s a bot, label AI content.
• Minimal: most other AI. No special obligations.

Fines reach €35M or 7% of global turnover, even steeper than GDPR. The signal is clear: AI governance is becoming a formal compliance discipline (model documentation, dataset governance, impact assessments), and US states like California are heading the same way with automated-decision rules.

Common misconceptions

• “GDPR doesn’t apply to us, we’re US-only.” It applies if you serve EU residents, full stop.
• “Consent is the safe default lawful basis.” Often contract or legitimate interests fits better, and bad consent is itself illegal.
• “We deleted the user, so we’re done.” Did you also clear backups, caches, logs, and third-party tools? If not, you haven’t deleted them.
• “Encrypting the CVV makes it okay to store.” No. Storing CVV at all is a PCI violation.
• “Privacy is the legal team’s job.” Legal can’t build a deletion pipeline or keep PII out of logs. You can.
• “Strong security means we’re compliant.” Security protects data; privacy governs whether you should hold it in the first place.

How to use this: the engineer’s checklist

Compliance turns into a finite list of things to build. Work through these:

1. Build a data map (RoPA). Document what PII you collect, why, where it lives, who you share it with, and how long you keep it. Nothing else is possible without this.
2. Build DSAR machinery. A reliable way to find, export, and delete one person’s data everywhere, including backups, caches, logs, and vendors.
3. Minimize and set retention. Don’t collect or keep what you don’t need. Automate deletion on a schedule.
4. Wire up real consent. Make it granular and withdrawable, and honor opt-out signals like the Global Privacy Control.
5. Turn on the security controls the laws now mandate. Encryption at rest and in transit, MFA, and least-privilege access.
6. Run a DPIA before risky or AI features. Treat it like a design review.
7. Rehearse breach response. Detection, logging, on-call, and a 72-hour runbook that names who notifies whom.
8. Sign a DPA or SCC with every vendor. Missing terms fueled the Honda and Healthline fines.
9. Make architecture region-aware. Pin databases to regions and make sure logs and analytics don’t quietly ship PII abroad.

And one rule worth tattooing on the team wiki:

Never write raw PII into application logs. Logs get replicated, shipped to third-party tools, and are rarely deletable per user. Log a stable user ID, never an email, name, or card number.

Conclusion

Here’s the single takeaway: privacy compliance is not about memorizing statutes, it’s about building machinery. A data map, deletion and export pipelines, real consent, encryption, region-aware architecture, and a rehearsed breach runbook. Build those, and you’ve turned a legal headache into ordinary engineering.

This shift also created an entire new career: privacy engineering, people who build privacy in rather than reviewing it after the fact. The professional body (IAPP) has doubled to over 120,000 members, and senior US roles clear $300K. If “make deletion actually work across 40 services” sounds like an interesting problem, you may already be a privacy engineer in disguise.

Next worth exploring: how techniques like differential privacy and data anonymization let you learn from data without ever holding the raw personal version of it. That’s where compliance stops being a constraint and starts becoming a design superpower.