Toolkit · Technology

The Privacy and Data Protection Toolkit: Building and Operating a Compliance Program

Type
Toolkit
Jurisdiction
National
Date
2025-06-09
Topic
Technology

This toolkit is a working roadmap for building, operating, and defending a privacy and data-protection program in the United States and across borders. It follows the program life cycle in the order a company actually lives it: mapping personal data, standing up governance, giving notice and collecting lawful consent, minimizing and retiring what it holds, and then satisfying a fractured body of law. That law includes the federal sectoral statutes (HIPAA, GLBA, COPPA), the fast-growing family of state comprehensive laws led by California's CCPA and CPRA, the FTC's Section 5 authority that behaves like a national privacy regulator, the EU's GDPR and its cross-border transfer rules after Schrems II, and biometric statutes such as Illinois's BIPA that carry a private right of action. It closes with breach response, litigation-standing exposure, and vendor management. Each stage states the operative rule, cites the controlling authority, works a hypothetical, and links to deeper UpLaw resources. It is written for privacy counsel, compliance leads, founders, and product teams who need both the strategic map and the specific rule for each step.

The Privacy and Data Protection Toolkit: Building and Operating a Compliance Program

Technology > Privacy | Published 9 June 2025 - Updated 17 October 2025 | UpLaw - uplaw.us

A stage-by-stage guide to constructing a privacy program that survives a regulator's questions, a plaintiff's complaint, and a customer's data-subject request — mapping the U.S. sectoral and state patchwork, the FTC's enforcement gravity, the GDPR, and biometric law onto one operating discipline.

Keywords: privacy program, data protection, data mapping, CCPA, CPRA, GDPR, HIPAA, GLBA, COPPA, BIPA, biometric privacy, data breach notification, incident response, cross-border data transfers, Schrems II, data minimization, vendor management, FTC Section 5, records of processing, data protection impact assessment

The problem this toolkit solves

The United States never passed a single privacy statute, and the absence shows. A company that collects personal data answers to a stack of overlapping regimes at once: federal statutes that regulate by sector (health data, financial data, children's data); a swelling roster of state comprehensive laws that regulate by residency, led by California; a Federal Trade Commission that polices "unfair or deceptive" data practices under a 1914 statute and, in doing so, has authored what two leading scholars call a "new common law of privacy," Daniel J. Solove & Woodrow Hartzog, The FTC and the New Common Law of Privacy, 114 Colum. L. Rev. 583 (2014); the European Union's General Data Protection Regulation, which reaches across the Atlantic to anyone offering goods or services to people in the EU; and a growing set of biometric statutes that hand plaintiffs a private right of action and statutory damages.

No one of these is the "privacy law." Together they form a compliance surface that changes every legislative session. The purpose of a privacy program is to impose a single operating discipline on top of that fragmentation — to know what personal data the organization holds, why it holds it, where the data sits, who touches it, and how each of those answers will hold up when a regulator, a class-action plaintiff, or a data subject asks. A program is not a policy document. It is the standing capability to answer those questions truthfully and to prove the answers.

This toolkit walks that capability into being. It follows the life cycle a program actually lives — inventory, governance, notice and consent, minimization, then the layers of law, then breach response and vendor oversight — and at each stage it gives the operative rule, the controlling authority, a worked hypothetical, and pointers to the deeper UpLaw resources that unpack the step. It is a map, not a compliance opinion. For the build-out detail, hand yourself to the privacy compliance program blueprint and the step-by-step program checklist; for each specialized topic, to the focused resource named under that stage.

A note on who should read which parts

A founder wiring privacy into a new app can read Stages 1 through 4 and Stage 11 and stop; the sectoral and international material may not touch a domestic consumer app until it scales. A compliance lead standing up a program from scratch should read straight through. A lawyer handling a live incident can jump to Stage 10 and work backward to the governance the incident will expose. The stages are ordered, but they are not strictly sequential in practice — mapping, minimization, and vendor diligence run continuously, and the legal-analysis stages (5 through 9) apply in whatever combination a given dataset triggers.

Roadmap at a glance

  1. Data mapping and inventory — knowing what personal data exists, where it lives, and where it flows.
  2. Governance — ownership, written policies, impact assessments, training, and an audit trail.
  3. Notice and consent — privacy notices, lawful bases, just-in-time disclosures, and honest interfaces.
  4. Minimization and retention — collecting and keeping only what a stated purpose requires.
  5. Federal sectoral law — HIPAA, GLBA, and COPPA.
  6. State comprehensive law — CCPA/CPRA and the multistate matrix.
  7. The FTC — Section 5 as the de facto national privacy regulator.
  8. GDPR and cross-border transfers — extraterritorial reach and moving data after Schrems II.
  9. Biometric privacy — BIPA, its private right of action, and the sensitive-data overlay.
  10. Breach and incident response — detection, privilege, notification deadlines, and standing.
  11. Vendors and acquired data — processor contracts, email marketing, and the provenance of data you ingest.

Stage 1 — Map the data before you touch anything else

Every downstream obligation depends on a single artifact that most organizations lack: an accurate inventory of the personal data they hold. You cannot minimize, secure, disclose lawfully, or delete on request data you have never catalogued. So the program starts with a data map — an inventory of the categories of personal data collected, the sources, the purposes of processing, the systems and repositories where the data resides, the people and roles with access, the third parties it flows to, and the retention period for each category.

The GDPR makes this a hard legal requirement rather than a best practice. Article 30 obliges most controllers and processors to maintain a written record of processing activities describing exactly these elements. Regulation (EU) 2016/679, art. 30. Even where no statute compels a formal record, the map is the practical predicate for everything else: it tells you which laws apply (Do you hold protected health information? Data from children under 13? Biometric identifiers? Personal data of EU or California residents?), it populates your privacy notices, it scopes your retention schedule, and it is the first document a regulator or breach-response team demands.

Build the map from three sources at once. Interview each business function about the data it collects and why. Scan systems and databases to catch shadow data the interviews miss — the marketing spreadsheet on someone's laptop, the analytics SDK nobody remembers integrating. And read the vendor contracts to trace where data leaves the building. Then keep it alive: a data map is accurate for about as long as it takes to launch the next feature. Treat it as a living register refreshed whenever a new system, vendor, data element, or data flow appears.

Worked example. Lumen, a hypothetical direct-to-consumer skincare startup, thinks of itself as a simple e-commerce shop. A proper data map tells a different story. It collects shipping addresses (contact data), payment tokens (financial data via a processor), a "skin quiz" that asks about acne and rosacea (arguably health-adjacent data), photographs users upload for an AI "shade match" feature (potential biometric exposure if the model analyzes facial geometry), email-marketing lists (CAN-SPAM and consent obligations), and behavioral analytics from a third-party pixel (a "sale" or "share" under California law). Before the map, Lumen believed it triggered no privacy statute worth worrying about. After the map, it can see at least four regimes in play. The map did not create the exposure; it revealed exposure that already existed.

The inventory also drives minimization, which is why the data-map step and the data minimization and storage-limitation program are two ends of the same discipline.

Authority and resources. GDPR art. 30 (records of processing); NIST Privacy Framework and the Fair Information Practice Principles as anchoring frameworks. See the privacy compliance program blueprint for mapping methodology and the program checklist for the inventory steps.

Stage 2 — Governance: give the program an owner and a spine

A program without an owner is a binder. Governance turns policy into an operating discipline by assigning accountability, writing the rules down, and building the paper trail that proves the rules are real.

Ownership. Designate a privacy officer accountable for the program. In some cases the law names the role: GDPR Article 37 requires a Data Protection Officer for public bodies, for controllers whose core activities involve large-scale systematic monitoring, and for large-scale processing of special-category data. Regulation (EU) 2016/679, art. 37. Even where no statute compels a DPO, a single accountable owner — with a direct line to leadership and the authority to halt a launch — is the difference between a program and an aspiration.

Written policies. Adopt the internal instruments the program runs on: a data-classification scheme, an acceptable-use policy, access-control standards, a retention schedule (Stage 4), and an incident-response plan (Stage 10). These are the controls a regulator asks to see and the standard against which an employee's conduct is measured after something goes wrong.

Impact assessments. Two documents carry outsized weight. A data protection impact assessment (DPIA) is mandatory under GDPR Article 35 whenever processing is "likely to result in a high risk to the rights and freedoms of natural persons" — new profiling, large-scale monitoring, or large-scale processing of sensitive data. Regulation (EU) 2016/679, art. 35. The state comprehensive laws import the same idea under a different name: the Virginia and Colorado statutes require a data protection assessment before high-risk processing such as targeted advertising, the sale of personal data, processing of sensitive data, and certain profiling. See Va. Code Ann. § 59.1-580; Colo. Rev. Stat. §§ 6-1-1301 to -1313. The related privacy impact assessment is the operational cousin — a structured review that bakes privacy into a new product or feature before launch rather than bolting it on after. Run one whenever a new processing activity would surprise a reasonable user or handle sensitive categories.

Training and records. Product managers, engineers, and marketers make the decisions that create privacy risk, usually without a lawyer in the room. Train them on the rules that touch their work and record that you did. Build a defensible process for handling individual-rights requests — access, deletion, correction, and opt-out — and keep a log of what was decided and why. Regulators and litigants reward a demonstrable, operating program and punish a paper one; the audit trail is what makes "operating" provable.

Worked example. A hypothetical fintech, Cedar Rail, wants to ship a feature that scores creditworthiness from users' transaction histories. Governance forces the questions before the code ships: Is a DPIA required (yes — automated profiling of financial data)? What lawful basis supports it? What notice does the user get? Who signed off? A year later, when a state attorney general asks how the model handles sensitive inferences, Cedar Rail can produce the assessment and the sign-off. The company that skipped the assessment can produce nothing, and the absence itself becomes evidence of an unfair practice.

Authority and resources. GDPR arts. 35, 37; Va. Code Ann. § 59.1-580; Colo. Rev. Stat. §§ 6-1-1301 to -1313. See the privacy compliance program blueprint for governance structure and the program checklist for DPIA and rights-request workflows.

Stage 3 — Notice and consent: the transparency backbone

Transparency is the load-bearing wall of privacy law. Almost every regime obliges an organization to tell people what it collects, why, with whom it shares, and how to exercise their rights — and several then require the person's permission before certain collection begins.

Notice. The content of a privacy notice varies by regime, and the differences matter:

  • GDPR prescribes the disclosures in Articles 13 (data collected from the individual) and 14 (data obtained elsewhere): identity of the controller, purposes and lawful basis, recipients, retention period, transfer mechanisms, and the individual's rights. Regulation (EU) 2016/679, arts. 13–14.
  • California requires a "notice at collection" that lists the categories of personal information collected and the purposes, plus a standing privacy policy and, where the business sells or shares data, a "Do Not Sell or Share My Personal Information" mechanism. Cal. Civ. Code §§ 1798.100, 1798.135.
  • COPPA requires direct notice to parents and a posted online notice before collecting personal information from children under 13. 15 U.S.C. §§ 6501–6506; 16 C.F.R. pt. 312.

Lawful basis and consent. Under the GDPR, notice alone is not enough; every processing activity needs a lawful basis from the Article 6 menu — consent, contract, legal obligation, vital interests, public task, or legitimate interests. Regulation (EU) 2016/679, art. 6. Where consent is the basis, Article 7 demands that it be "freely given, specific, informed and unambiguous," and as easy to withdraw as to give. For special-category data — health, biometrics, race, religion, sexual orientation — Article 9 raises the bar to explicit consent or another narrow exception. In the United States, consent is mandatory in pockets rather than across the board: verifiable parental consent under COPPA, informed written consent under Illinois's biometric statute (Stage 9), and opt-in consent for sensitive-data processing under several state laws.

Just-in-time notice and honest interfaces. A privacy policy buried three taps deep does not fairly disclose a surprising practice. Where a data use would startle the user — precise geolocation, microphone or camera access, sharing with data brokers — give a just-in-time notice at the point of collection. And design the consent interface honestly. Both the FTC and the California regime now treat dark patterns — interfaces engineered to nudge users into "consenting" — as legally defective; California states outright that consent obtained through a dark pattern is not consent. Cal. Civ. Code § 1798.140(h). A pre-checked box, a confirm-shaming decline button, or an opt-out buried under five clicks can convert a compliance feature into an enforcement exhibit.

Worked example. Waypoint, a hypothetical rideshare app, wants continuous background location so it can pre-position drivers. A single line in a 4,000-word policy will not carry it. The defensible pattern is a just-in-time prompt when the feature is first used — plain language on what is collected, why, and how to turn it off — paired with an OS-level permission the user actively grants. If Waypoint instead labels the "allow always" button in bright green and the "only while using" button in gray six-point type, it has built a dark pattern, and the consent it harvested is worth nothing when a regulator looks at the screen.

For the app-specific layer — SDK disclosures, platform rules, and store-review requirements — see mobile app privacy law and the pre-launch legal checklist for mobile apps. For device-sensor capture — cameras, microphones, recording — see cameras, consent, and the law of recording people.

Authority and resources. GDPR arts. 6, 7, 9, 13, 14; Cal. Civ. Code §§ 1798.100, 1798.135, 1798.140(h); COPPA, 15 U.S.C. §§ 6501–6506, 16 C.F.R. pt. 312.

Stage 4 — Collect less, keep less: minimization and retention

The cheapest way to reduce breach exposure is to hold less data, because data you never collected cannot be stolen, subpoenaed, or misused. Data minimization — collecting only what a stated purpose requires — is both a substantive legal duty and the single most effective risk-reduction move a program can make.

The duty is explicit in the law. GDPR Article 5(1)(c) requires personal data to be "adequate, relevant and limited to what is necessary" for the purpose; Article 5(1)(e) adds storage limitation — keep data no longer than the purpose requires. Regulation (EU) 2016/679, art. 5(1)(c), (e). California's CPRA imports the same principle: a business may collect and use personal information only as "reasonably necessary and proportionate" to the disclosed purpose. Cal. Civ. Code § 1798.100(c). And the FTC has treated the indefinite hoarding of unnecessary personal data as itself an unfair practice in its data-security orders.

Build a retention schedule tied to the map. For each data category in the Stage 1 inventory, define how long it is kept, on what legal or business justification, and how it is deleted or de-identified when the clock runs out. Then implement deletion technically, not just on paper — an unenforced retention policy is worse than none, because it documents a rule the organization knowingly breaks. Wire in a legal-hold mechanism that suspends deletion for data under litigation duty, and make sure the hold is scoped and released, not left running forever.

Worked example. Northbrook Fitness, a hypothetical gym chain, kept every prospect's inquiry form — name, email, and health goals — indefinitely, "in case they came back." Ten years of dead leads sat in a marketing database nobody secured. When an attacker exfiltrated it, the breach swept in hundreds of thousands of records that served no current purpose and should have been purged years earlier. Over-retention did not cause the intrusion, but it multiplied the harm, the notification population, and the regulatory exposure. A retention schedule that deleted inactive leads after 24 months would have shrunk the breach to a fraction of its size.

Minimization is not a one-time purge; it is a standing practice of periodic review and defensible deletion. UpLaw's data minimization and storage-limitation guide works the retention-schedule build and the deletion mechanics in depth.

Authority and resources. GDPR art. 5(1)(c), (e); Cal. Civ. Code § 1798.100(c); FTC data-security consent orders.

Stage 5 — Federal sectoral law: HIPAA, GLBA, COPPA

Federal privacy law in the United States regulates by industry, not across the board. Three statutes cover the sectors most companies touch, and a single organization can fall under several at once. The Stage 1 map tells you which apply.

HIPAA — health data

The Health Insurance Portability and Accountability Act governs protected health information held by "covered entities" — health-care providers, health plans, and clearinghouses — and, critically, by their business associates: the vendors that create, receive, maintain, or transmit PHI on a covered entity's behalf, including cloud hosts, analytics providers, and increasingly AI vendors. 45 C.F.R. pts. 160, 164; see id. § 160.103 (business-associate definition). Two obligations dominate:

  • Business associate agreements. A covered entity may share PHI with a business associate only under a written BAA that binds the vendor to HIPAA's requirements and specifies permitted uses. 45 C.F.R. § 164.504(e). The obligation flows downstream to subcontractors.
  • The Security Rule. Covered entities and business associates must implement administrative, physical, and technical safeguards for electronic PHI — risk analysis, access controls, audit logging, encryption where reasonable. 45 C.F.R. §§ 164.302–318.

The line between a regulated "business associate" and an unregulated "mere conduit" (a vendor that only transmits data without accessing it) is where much of the fighting happens, and getting it wrong means storing PHI with no BAA and no safeguards. UpLaw's HIPAA-in-the-cloud guide works the conduit exception, the required BAA terms, and the shared-responsibility model with the cloud provider.

GLBA — financial data

The Gramm-Leach-Bliley Act protects the nonpublic personal information of individuals who obtain financial products or services for personal, family, or household use. Subtitle A of Title V splits into two rules. The Financial Privacy Rule requires financial institutions to deliver privacy notices and to let consumers opt out before the institution shares NPI with unaffiliated third parties. The Safeguards Rule, implemented by the FTC at 16 C.F.R. Part 314, requires a written information security program with administrative, technical, and physical safeguards scaled to the institution's size, complexity, and the sensitivity of the data. 15 U.S.C. §§ 6801–6809; 16 C.F.R. pt. 314. The FTC's amended Safeguards Rule now prescribes specific elements — a designated qualified individual to run the program, a written risk assessment, access controls, encryption, and multifactor authentication — moving GLBA from a general standard toward a checklist.

COPPA — children's data

The Children's Online Privacy Protection Act governs the online collection of personal information from children under 13. It requires direct notice to parents, verifiable parental consent before collection, data-minimization and retention limits, and reasonable security, all enforced by the FTC. 15 U.S.C. §§ 6501–6506; 16 C.F.R. pt. 312. The FTC's recent COPPA Rule amendments tightened consent mechanics and expanded the definition of covered personal information (including certain biometric and persistent identifiers), so any product that a child could plausibly use — a game, an education app, a general-audience service with child users — needs a deliberate age-screening and parental-consent design, not an afterthought.

Worked example. Marlowe Health, a hypothetical telehealth startup, builds a symptom-checker for teens. It is a business associate to the clinics it serves (HIPAA), it processes children's data if under-13 users slip through (COPPA), and if it later adds a "pay over time" financing option it may pull GLBA-covered financial data into scope. One product, three federal regimes, each with its own contract, notice, and safeguard requirement. The map, again, is what surfaces the overlap before a regulator does.

Authority and resources. HIPAA Privacy and Security Rules, 45 C.F.R. pts. 160, 164; GLBA, 15 U.S.C. §§ 6801–6809 and 16 C.F.R. pt. 314; COPPA, 15 U.S.C. §§ 6501–6506 and 16 C.F.R. pt. 312. See the HIPAA-in-the-cloud guide and, for youth-facing products, mobile app privacy law.

Stage 6 — State comprehensive law: California leads, the rest follow

Where Congress left gaps, the states filled them. California moved first and set the template the others copied with variations.

The California regime: CCPA and CPRA

The California Consumer Privacy Act, expanded by the California Privacy Rights Act, gives California residents rights to know, access, delete, and correct their personal information, and to opt out of its "sale" or "sharing." Cal. Civ. Code § 1798.100 et seq. The CPRA added three things worth flagging:

  • A category of "sensitive personal information" — precise geolocation, race, health, biometrics, contents of communications — with a right to limit its use. Cal. Civ. Code § 1798.140.
  • A dedicated regulator, the California Privacy Protection Agency, with rulemaking and enforcement authority — the first agency of its kind in the country.
  • A limited private right of action for consumers whose nonencrypted, nonredacted personal information is exposed in a breach caused by a failure to maintain reasonable security. Cal. Civ. Code § 1798.150. This provision matters far beyond California, because it converts a security lapse into class-action fuel with statutory damages of $100 to $750 per consumer per incident.

The multistate matrix

California is no longer alone or even unusual. Virginia's Consumer Data Protection Act (Va. Code Ann. § 59.1-575 et seq.), the Colorado Privacy Act (Colo. Rev. Stat. §§ 6-1-1301 to -1313), Connecticut, Utah, Texas, Oregon, Montana, and a lengthening list of others have enacted comprehensive privacy laws. They share a common architecture — controller/processor roles borrowed from the GDPR, consumer rights to access and delete, opt-outs for targeted advertising and sale, sensitive-data protections, and data protection assessments — but they diverge on thresholds, definitions, cure periods, and enforcement.

The practical consequence for a national business is a reconciliation problem. Three tactics manage it:

  1. Harmonize up. Where the laws differ, build to the strictest common denominator so one workflow satisfies all — universal opt-out signals, a single rights-request intake, one sensitive-data consent flow.
  2. Track the thresholds. Coverage turns on revenue and data-volume triggers that differ by state; know which lines your business has crossed.
  3. Treat the matrix as living. A new state law passes nearly every session, and existing regulators issue rules continuously. A state-law compliance matrix is a document you update, not one you finish.

Worked example. Lumen from Stage 1, now selling nationwide, receives a deletion request from a Colorado customer and, a week later, an identical request from a Texas customer. If Lumen built one rights-request pipeline keyed to the strictest requirements, both are routine. If it built a California-only workflow because California came first, it now discovers — under a statutory clock — that it has no process for the other forty-nine states. The harmonize-up strategy is not perfectionism; it is the only design that scales.

Authority and resources. CCPA/CPRA, Cal. Civ. Code § 1798.100 et seq.; CPPA regulations; Va. Code Ann. § 59.1-575 et seq.; Colo. Rev. Stat. §§ 6-1-1301 to -1313. See the program checklist for consumer-rights workflows and the privacy compliance program blueprint for the multistate build.

Stage 7 — The FTC: the de facto national privacy regulator

There is a regulator that touches nearly every company on this list even though no privacy statute names it. Section 5 of the FTC Act bars "unfair or deceptive acts or practices in or affecting commerce," 15 U.S.C. § 45(a), and for two decades the Commission has read that language to reach data privacy and security. The mechanism is deceptively simple. A company that promises "bank-level encryption" and delivers none has committed a deception. A company that stores sensitive data with security so weak that consumers cannot avoid the resulting harm has committed an unfairness. Either supports an enforcement action, and the Commission has brought hundreds, most resolved by consent decrees that impose twenty-year compliance programs.

Two appellate decisions define the outer walls of this authority. In FTC v. Wyndham Worldwide Corp., 799 F.3d 236 (3d Cir. 2015), the Third Circuit upheld the FTC's power to police unreasonable data security as an "unfair" practice, rejecting the argument that the agency needed a specific security regulation before it could act. Three years later, in LabMD, Inc. v. FTC, 894 F.3d 1221 (11th Cir. 2018), the Eleventh Circuit trimmed the remedy, holding that an FTC order commanding a company to implement "reasonable" security in the abstract was too vague to enforce. Together they mean the Commission can reach lax security under a general statute but must write orders concrete enough to obey.

The consequence for program design is that the FTC's consent decrees function as de facto rules. When the Commission repeatedly requires multifactor authentication, encryption, vendor oversight, and a designated security officer as terms of settlement, those terms become the market's understanding of "reasonable" security — the "new common law of privacy" that Solove and Hartzog described. A program built only to the letter of the state statutes, ignoring the FTC's accumulated body of orders, is built to the wrong standard. And because Section 5 reaches "deception," the single most dangerous document a company owns is its own privacy policy: every promise in it is an FTC-enforceable representation. Promise less, and keep every promise you make.

Worked example. A hypothetical analytics company tells customers it "never sells your data" while quietly sharing device identifiers with ad networks under a definition of "sell" it invented for itself. There may be no state statute the company technically violates. There is still a Section 5 deception, because the representation misled reasonable consumers. The FTC does not need a privacy statute; it needs a broken promise.

This enforcement gravity connects to the broader story of U.S. technology regulation traced in the evolution of computer law, and it overlaps heavily with advertising and marketing rules covered in the advertising-law FAQ for small businesses.

Authority and resources. FTC Act § 5, 15 U.S.C. § 45; FTC v. Wyndham Worldwide Corp., 799 F.3d 236 (3d Cir. 2015); LabMD, Inc. v. FTC, 894 F.3d 1221 (11th Cir. 2018); Solove & Hartzog, The FTC and the New Common Law of Privacy, 114 Colum. L. Rev. 583 (2014).

Stage 8 — GDPR and cross-border transfers

The General Data Protection Regulation is the most consequential privacy law on earth for one reason: it does not stop at the EU's borders. Article 3 extends the Regulation to any organization, wherever located, that offers goods or services to people in the EU or monitors their behavior. Regulation (EU) 2016/679, art. 3. A U.S. company with EU customers, EU website visitors it tracks, or EU employees is inside the GDPR whether or not it has a European office.

Inside the Regulation, the obligations are demanding: a lawful basis for every processing activity (Stage 3), the full suite of data-subject rights, breach notification to the supervisory authority within 72 hours (Stage 10), DPIAs for high-risk processing (Stage 2), and a fine ceiling that concentrates the mind — up to €20 million or 4% of total worldwide annual turnover, whichever is higher, for the most serious violations. Regulation (EU) 2016/679, art. 83(5). Article 82 adds a private right to compensation for individuals who suffer damage, material or non-material.

The transfer problem

The hardest GDPR question for a U.S. company is not whether it can process EU data but whether it can move that data to the United States. Chapter V of the GDPR forbids transferring personal data outside the European Economic Area unless an adequate safeguard travels with it. The history is a decade of the EU striking down the safeguards U.S. companies relied on:

  • In Schrems I, the Court of Justice invalidated the U.S.–EU Safe Harbor. Schrems v. Data Protection Comm'r, Case C-362/14 (CJEU 2015).
  • In Schrems II, the Court invalidated the successor Privacy Shield, holding that U.S. surveillance law gave EU data subjects no adequate redress. Data Protection Comm'r v. Facebook Ireland Ltd. & Schrems, Case C-311/18 (CJEU 2020). Crucially, the Court left Standard Contractual Clauses standing — but only if the exporter first conducts a transfer impact assessment evaluating whether the destination country's surveillance regime undermines the clauses, and adopts supplementary measures (encryption, pseudonymization, contractual commitments) where it does.

The current mechanisms are three. A U.S. importer can self-certify under the EU–U.S. Data Privacy Framework, the adequacy decision the European Commission adopted in July 2023, which restores a streamlined path for certified companies — though, like its predecessors, it faces pending legal challenge. Or the parties can use SCCs plus a transfer impact assessment, documenting the analysis Schrems II requires. Or a corporate group can adopt Binding Corporate Rules approved by a supervisory authority for intra-group transfers. Whichever you choose, map the transfers, pick a mechanism, and paper the analysis — the assessment, not just the clause, is what defends the transfer.

Worked example. Lumen opens EU sales and routes European customer records to a U.S. cloud region. Three compliant paths exist: confirm the cloud provider is DPF-certified and rely on adequacy; or execute SCCs with the provider and run a transfer impact assessment on the U.S. region; or, if Lumen has an EU subsidiary, move data intra-group under Binding Corporate Rules. What Lumen cannot do is what most companies do by default — transfer the data with no mechanism at all and hope no regulator notices.

UpLaw treats the transfer machinery in depth in moving personal data out of the EU after Schrems II, including the SCC modules, the transfer-impact-assessment method, supplementary measures, and the parallel UK regime.

Authority and resources. GDPR arts. 3, 5–6, 33–35, 44–49, 82, 83(5); Schrems v. Data Protection Comm'r, C-362/14 (CJEU 2015); Data Protection Comm'r v. Facebook Ireland & Schrems, C-311/18 (CJEU 2020); EU–U.S. Data Privacy Framework adequacy decision (2023).

Stage 9 — Biometric privacy: the litigation magnet

Biometric identifiers — fingerprints, faceprints, voiceprints, iris scans — carry a risk no password does: they cannot be reset. A breached credential is replaced in seconds; a breached faceprint is compromised for life. The law has responded, and one statute has generated more privacy litigation than any other in the country.

Illinois BIPA

The Illinois Biometric Information Privacy Act is the statute that matters most, because it does what almost no other privacy law does: it hands the individual a private right of action. 740 ILCS 14/20. Before collecting a person's biometric identifier, a private entity must (1) inform the person in writing that the data is being collected and for how long it will be kept and used, and (2) obtain the person's informed written consent — a "written release." 740 ILCS 14/15(b). The entity must also publish a written retention-and-destruction policy and destroy biometric data when the collection purpose ends or within three years of the individual's last interaction, whichever comes first. 740 ILCS 14/15(a). Sale of biometric data is prohibited.

The damages are what drive the class actions. A prevailing plaintiff recovers, for each negligent violation, the greater of actual damages or $1,000, and for each intentional or reckless violation, the greater of actual damages or $5,000, plus attorneys' fees and injunctive relief. 740 ILCS 14/20. Two Illinois Supreme Court decisions turned those numbers into an existential exposure:

  • In Rosenbach v. Six Flags Entertainment Corp., 2019 IL 123186, the court held that a plaintiff is "aggrieved" — and may sue — on the bare statutory violation, with no need to prove separate actual injury. A fingerprint scan taken without the required consent is itself the harm.
  • In Cothron v. White Castle System, Inc., 2023 IL 32, 216 N.E.3d 918, the court held that a separate claim accrues with each scan or transmission, not just the first. For an employer that scanned a worker's fingerprint at every shift for years, the per-violation math becomes ruinous, which is exactly why BIPA cases settle for tens and hundreds of millions.

Beyond Illinois

Texas and Washington regulate biometrics but reserve enforcement to their attorneys general. Texas's Capture or Use of Biometric Identifier Act carries civil penalties up to $25,000 per violation but no private suit. Tex. Bus. & Com. Code Ann. § 503.001. Washington's biometric statute is similar. RCW 19.375. And the state comprehensive laws (Stage 6) increasingly classify biometric data as sensitive data requiring opt-in consent and a data protection assessment, layering a second obligation on top of the dedicated statutes.

For any product using facial recognition, voice authentication, or fingerprint login — and for AI systems trained on biometric data — build the consent, notice, retention, and destruction controls before collection begins, not after the first demand letter. The failure mode here is a class action, not a regulator's advisory letter. UpLaw's biometric privacy law and the AI systems that read faces and voices works the statutes and their consequences for AI developers, and the broader key legal issues in artificial intelligence guide situates biometrics within AI risk generally.

Worked example. A hypothetical warehouse operator installs fingerprint time clocks in an Illinois facility to stop "buddy punching," and never asks anyone to sign a release. Under Rosenbach, every worker has a claim on the first scan; under Cothron, the claims multiply with every subsequent scan across every shift. A cost-saving efficiency became a nine-figure liability, and the only thing that would have prevented it was a one-page consent form and a published retention policy — the two documents BIPA required from the start.

Authority and resources. BIPA, 740 ILCS 14/1 et seq.; Rosenbach v. Six Flags Ent. Corp., 2019 IL 123186; Cothron v. White Castle Sys., Inc., 2023 IL 32, 216 N.E.3d 918; Tex. Bus. & Com. Code Ann. § 503.001; RCW 19.375.

Stage 10 — Breach and incident response

When data is lost or stolen, the program's quality is measured in the first 48 hours. A breach-response capability has four moving parts, and each has a legal edge.

Detection. You cannot respond to what you cannot see. Monitoring, logging, and an escalation path turn a silent intrusion into a triggered response. The gap between compromise and discovery is the single biggest driver of breach severity and of regulatory criticism.

Containment and investigation — under privilege. Once an incident is suspected, engage forensics and outside counsel and structure the investigation to preserve attorney-client privilege and work-product protection. This is not a formality. Courts have compelled production of forensic breach reports that were commissioned as ordinary business records rather than genuinely in anticipation of litigation, handing plaintiffs the company's own roadmap of its failures. Retain the forensic firm through counsel, scope the engagement to litigation, and keep the ordinary-course security work on a separate track. For organizations that hold trade secrets alongside personal data, the same intrusion threatens intellectual property, and the forensic documentation that protects one can waive privilege that protects the other — a trap worked in protecting trade secrets during a data breach and the trade secret incident-response checklist.

Notification — every clock at once. The hardest part of breach response is that the deadlines run in parallel under different laws:

  • All fifty states have breach-notification statutes, each with its own definition of covered data, timing, and content. Some — including California, Illinois, and New Jersey — attach a private right of action to notification failures. Sector statutes carve exemptions for HIPAA covered entities and GLBA-regulated institutions, but only if they notify under those federal regimes instead.
  • HIPAA requires notice to affected individuals without unreasonable delay and no later than 60 days, plus notice to HHS. 45 C.F.R. §§ 164.400–414.
  • GDPR requires notice to the supervisory authority within 72 hours of awareness, and to affected data subjects without undue delay where the breach poses a high risk. Regulation (EU) 2016/679, arts. 33–34.
  • California's CCPA private right of action lets consumers sue for statutory damages after a breach of unencrypted personal information caused by unreasonable security. Cal. Civ. Code § 1798.150.

Remediation. Close the vulnerability, and document the improvement. A breach that produces no change in the control environment is the fact pattern regulators and plaintiffs use to argue the company was indifferent.

The standing wrinkle

Not every data breach yields a viable class action, because federal plaintiffs must show a concrete injury to satisfy Article III standing. In Spokeo, Inc. v. Robins, 578 U.S. 330 (2016), the Supreme Court held that a bare statutory violation, without concrete harm, does not confer standing. In TransUnion LLC v. Ramirez, 594 U.S. 413 (2021), the Court sharpened the point: plaintiffs whose inaccurate credit files were never disclosed to a third party had suffered no concrete harm and could not sue in federal court, even though the statute was violated as to all of them. The result is a live circuit split over when the mere risk of future identity theft from a breach — as opposed to realized misuse — is concrete enough to sue. That split is why some breach classes survive and others collapse at the pleading stage, and why defense counsel scrutinize whether the exposed data was actually misused. (State courts, unbound by Article III, may take a more permissive view, which is part of why plaintiffs often prefer them.)

Prepare before the incident. Maintain a written incident-response plan, a contact tree, pre-vetted forensic and notification vendors, and template notices. The company that assembles its response team during the breach loses the first 48 hours — the hours that decide everything.

Authority and resources. HIPAA Breach Notification Rule, 45 C.F.R. §§ 164.400–414; GDPR arts. 33–34; state breach-notification statutes; Cal. Civ. Code § 1798.150; Spokeo, Inc. v. Robins, 578 U.S. 330 (2016); TransUnion LLC v. Ramirez, 594 U.S. 413 (2021).

Stage 11 — Vendors and the data you acquire

Personal data almost never stays inside one company. Cloud hosts, analytics providers, marketing platforms, payment processors, and AI tools all touch it — and, as a rule, the controller stays responsible for what its processors do with it. A vendor-management process has three phases.

Diligence before onboarding. Assess the vendor's security posture, certifications, breach history, and sub-processors before data flows. A vendor with weak security is your weak security, and the FTC (Stage 7) has repeatedly treated inadequate vendor oversight as an unfair practice in its own right.

The right contract, every time. The paper depends on the relationship: a data processing agreement under GDPR Article 28 (which prescribes the mandatory terms for processor contracts), a business associate agreement under HIPAA, service-provider or contractor terms under the CCPA that restrict the vendor's use of the data, and SCCs where the arrangement moves data across borders (Stage 8). Regulation (EU) 2016/679, art. 28. The contract is where the controller's legal duties become the processor's enforceable obligations. The data-terms review that belongs in every vendor agreement overlaps with the software-licensing discipline covered in the software and open-source licensing toolkit and, for open-source components, the open-source compliance playbook.

Ongoing oversight. Diligence is not a one-time gate. Reassess vendors, monitor sub-processor changes, and audit against the contract over the life of the relationship.

Two adjacent risks worth naming

Email marketing. The CAN-SPAM Act governs commercial email — accurate header information, honest subject lines, clear identification as an advertisement, a physical postal address, and a working opt-out honored promptly. 15 U.S.C. §§ 7701–7713; 16 C.F.R. pt. 316. It overlaps with state and EU consent rules and with the TCPA for text and call channels. UpLaw treats the mechanics in the CAN-SPAM compliance guide and its companion CAN-SPAM checklist.

Acquired and scraped data. Data bought from a broker or harvested from the open web carries the privacy liability of its origin. The hiQ Labs v. LinkedIn litigation maps the tangle of Computer Fraud and Abuse Act, breach-of-contract, and copyright exposure that follows web scraping, and the Supreme Court's narrowing of the CFAA in Van Buren v. United States, 593 U.S. 374 (2021), reshaped when access becomes unauthorized. Feeding scraped personal data — or an unvetted purchased dataset — into your systems can import someone else's privacy violations as your own, a growing exposure as companies acquire data to train AI models. Vet the provenance of every dataset you ingest. The full analysis lives in web scraping and the law after hiQ v. LinkedIn.

Worked example. Waypoint, the rideshare app, buys a "traffic and mobility" dataset to improve routing, unaware that the vendor assembled it by scraping a competitor's app in violation of that app's terms and by combining location traces that re-identify individuals. Waypoint now holds personal data it has no lawful basis to process, acquired through conduct that may violate the CFAA and contract law, and it inherited every defect at the moment of purchase. A provenance clause in the vendor contract and a diligence question about how the data was collected would have surfaced the problem before the wire cleared.

Authority and resources. GDPR art. 28; CCPA service-provider provisions, Cal. Civ. Code § 1798.140; HIPAA BAA rule, 45 C.F.R. § 164.504(e); CAN-SPAM Act, 15 U.S.C. §§ 7701–7713 and 16 C.F.R. pt. 316; Van Buren v. United States, 593 U.S. 374 (2021).

Putting it together: a build sequence

The eleven stages are a reference, not a to-do list you finish once. In practice a program matures along a sequence:

  1. Map first (Stage 1). Nothing downstream is trustworthy without the inventory.
  2. Stand up governance and minimization (Stages 2, 4). An owner, written policies, a retention schedule, and impact assessments create the machinery the legal stages plug into.
  3. Fix notice and consent (Stage 3). These are the most public, most easily audited elements — and the ones the FTC reads as promises.
  4. Apply the law your map triggers (Stages 5–9). Sectoral, state, FTC, GDPR, and biometric obligations attach in whatever combination your data demands. Most companies discover they trigger more than they expected.
  5. Build breach and vendor capabilities before you need them (Stages 10–11). The incident-response plan and the vendor-contract templates are worthless if assembled during the crisis.

A program built this way is defensible not because it is perfect — no program is — but because it is demonstrable. It can produce the map, the assessments, the consent records, the vendor contracts, and the incident plan on demand. That evidentiary posture is what distinguishes a company that made reasonable efforts from one that will be treated as indifferent, and the difference between those two characterizations is, very often, the difference between a manageable exposure and a catastrophic one.

Privacy is also converging with adjacent disciplines faster than the statutes acknowledge. Trade-secret protection and breach response now share the same incident, as the trade secret protection toolkit explains; AI development runs headlong into biometric and data-processing law, as the AI and emerging technology toolkit maps; and product launches fold privacy into a broader legal checklist, worked in from feature-complete to live. A privacy program that ignores those seams solves for one exposure and misses the others.

Master resource index

Primary authority

Secondary authority

  • Daniel J. Solove & Woodrow Hartzog, The FTC and the New Common Law of Privacy, 114 Colum. L. Rev. 583 (2014).
  • Daniel J. Solove & Paul M. Schwartz, Information Privacy Law (treatise).
  • Samuel D. Warren & Louis D. Brandeis, The Right to Privacy, 4 Harv. L. Rev. 193 (1890) (the doctrine's origin point).
  • NIST Privacy Framework and the Fair Information Practice Principles.

Official sources

  • California AG, oag.ca.gov/privacy/ccpa; California Privacy Protection Agency, cppa.ca.gov.
  • HHS HIPAA, hhs.gov/hipaa; FTC privacy and security guidance, ftc.gov/business-guidance/privacy-security.
  • GDPR text, gdpr.eu; EU–U.S. Data Privacy Framework, dataprivacyframework.gov.
  • NIST Privacy Framework, nist.gov/privacy-framework.

Related UpLaw Resources

Related Guides

Related Checklists

Related Articles

Related Toolkits

This toolkit is a general research resource, not legal advice. U.S. privacy law changes constantly — new state statutes pass nearly every legislative session, the EU–U.S. Data Privacy Framework faces ongoing challenge, breach-notification deadlines differ by jurisdiction, and biometric-litigation doctrine keeps moving. Confirm the current text of any statute, regulation, decision, or deadline against the official sources before relying on it.