Standing Up a Privacy Compliance Program: A Practical Checklist

Technology > Privacy | Published 28 December 2025 - Updated 14 May 2026 | UpLaw - uplaw.us

A privacy program is not a document you finish; it is a system you run. This checklist stands one up in the order the work has to happen — accountable owner, data map, legal analysis, framework, roadmap, operating machinery, and proof — with the reasoning, the hypotheticals, the failure modes, and the authority behind each step.

Keywords: privacy compliance program, chief privacy officer, data protection officer, data mapping, record of processing, FTC Section 5, CCPA, CPRA, GDPR, state privacy laws, HIPAA, GLBA, COPPA, NIST Privacy Framework, DSAR, data processing agreement, DPIA, privacy by design, data minimization, breach notification

Most companies discover they are data businesses on a bad day. A deletion request arrives that no one can honor because no one knows where the data sits. A regulator sends a letter that begins with the words "we have received a complaint." A plaintiff's firm files a putative class action tied to a breach, and the demand letter is oddly specific about the number of records exposed. In each case the company's first internal conversation is the same panicked question — what do we actually have, and where? — and the answer is almost always a shrug.

The organizations that survive those days are rarely the ones with the thickest privacy policy. They are the ones with a program: a living arrangement of people, processes, and documentation that lets the business say, on demand, what personal data it holds, why it holds it, what the law requires, and how it proves all of that to a skeptical outsider. The distinction between a policy and a program is the entire subject of this checklist. A policy is a document, and a document goes stale the instant the ink dries. A program adapts, because privacy law changes month to month, your data changes day to day, and your vendor roster changes every quarter. The word to keep in mind is not compliance — a static, one-time image of a moving target — but operations.

Work this checklist roughly in sequence. Governance and a data map come first for a reason: nearly every downstream decision depends on knowing who owns the problem and what data is in scope. Skip either and you will build the rest of the program on sand. Nothing here is legal advice for your circumstances; privacy law is jurisdiction-specific and moves quickly, and the application of any rule to your facts is a job for counsel. For the narrative companion to this checklist, see UpLaw's guide to building a privacy compliance program; for the full life-cycle resource set, see the privacy and data protection toolkit.

To keep the abstractions honest, this checklist follows a single invented company through each phase. Meet Tidewater Provisions, a hypothetical 400-person direct-to-consumer brand that sells a subscription meal-and-supplement service. Tidewater ships nationwide and to the European Union, runs a companion mobile app that ingests sleep and activity data from an optional wrist wearable, and operates a "Tidewater Junior" nutrition tracker aimed at families. Nobody at Tidewater thinks of it as a data company. By the only definition that matters to a regulator, it is one of the larger data operations in its market — and it is exposed, without knowing it, to the CCPA, the GDPR, COPPA, biometric law, and the FTC's baseline authority all at once. The company is fictional; the exposures are entirely real.

Phase 1 — Governance: Put a Name on the Risk

• [ ] Secure a senior sponsor — general counsel, chief compliance officer, or the CEO — and a board-level acknowledgment that data handling is an enterprise risk, not an IT line item
• [ ] Choose a structure: the chief privacy officer (CPO) model, one accountable person vested with real authority, over the diffuse working-group or "privacy council" model
• [ ] Grant the privacy lead authority to set policy and to tell a revenue team it cannot ship a feature as designed
• [ ] Determine whether the GDPR or UK GDPR compels appointment of a data protection officer (DPO) with statutory independence (Arts. 37–39) and protection from retaliation for doing the job
• [ ] Wire in named cross-functional liaisons across legal, IT/security (the CIO and CISO), marketing and sales, human resources, records management, and internal audit
• [ ] Write down the escalation path: who decides when privacy and product disagree, and who breaks the tie

A privacy program lives or dies on one question: who, by name, is accountable when something goes wrong? If the honest answer is "everyone," the operational answer is "no one," and the program is theater — an elaborate set with no one authorized to move the furniture. The most dangerous configuration is not the company with no privacy function; it is the company with a privacy function that has responsibility but no authority. That office generates liability for a living, because it documents in writing, in email after email, all the things the company knew it should do and then chose not to do. When the regulator or the plaintiff arrives, those emails are Exhibit A.

The CPO model versus the committee

There is a reason mature programs converge on a single accountable owner. Diffused ownership erodes, predictably and always, into no ownership. A cross-functional "privacy council" that meets quarterly and votes by consensus produces minutes, not decisions. The CPO model places accountability on one identifiable person and gives a clean answer to the question every enforcement action eventually asks: who was responsible? That person does not have to do everything — a good CPO is a conductor, not a soloist — but the buck stops at a desk with a name on it.

Consider Tidewater. Suppose product engineering wants to add a feature that shares wearable sleep data with a third-party "wellness insights" partner in exchange for a revenue share. Under a council model, the idea circulates, marketing loves it, legal has "concerns," and the feature ships while the concerns are still being scheduled for discussion. Under the CPO model, one person with authority looks at the data map, sees that the sleep data was collected under a notice that promised it would not be sold or shared with third parties for their own purposes, and says: not as designed. That authority — the power to stop a shipment — is the difference between a program and a suggestion box.

When the GDPR forces a DPO

If any part of the business touches the European Union, the analysis has a second layer. Article 37 of the General Data Protection Regulation, Regulation (EU) 2016/679, requires a designated data protection officer in three situations: where processing is carried out by a public authority; where the core activities consist of regular and systematic monitoring of data subjects on a large scale; or where the core activities consist of large-scale processing of special-category data. Tidewater's wearable, which continuously monitors activity and sleep for EU customers, is exactly the kind of "regular and systematic monitoring" that can trip the requirement.

The statutory design of the DPO role is easy to underappreciate. Articles 38 and 39 do not merely require that a DPO exist; they require that the DPO be given independence, be involved in all data-protection matters "properly and in a timely manner," report to the highest management level, and — critically — not be dismissed or penalized for performing the role. A DPO who can be fired for delivering bad news is not a DPO within the meaning of the regulation; the title is decorative. The practical lesson generalizes beyond the EU: privacy authority that evaporates the moment it becomes inconvenient was never authority at all.

Cross-functional wiring

Privacy is a horizontal function stretched across vertical silos, which is why the governance layer has to name specific liaisons rather than gesture at departments. Security controls live with the CISO; marketing owns the consent banners and the ad-tech pixels; HR holds employee and applicant data (its own regulated category, and the subject of UpLaw's checklist on drafting an employee handbook that holds up); records management owns retention; internal audit provides the independent check discussed in Phase 6. Name a person in each function, put the names in the program charter, and give each one a standing obligation to loop in the privacy office before, not after, a decision is made.

Trap: the "part-time privacy officer" who is really the general counsel with a new hat and no new hours. Privacy is not a rounding error on someone else's job; a program run in the margins of another full-time role produces margin-quality results.

Phase 2 — Map the Data Before You Draft a Word

• [ ] For every meaningful category of personal information, capture: what is collected, whether any of it is sensitive (Social Security numbers, health, financial, precise geolocation, biometrics, children's data), where it lives inside and outside the company, cross-border flows, the security wrapped around it, and the internal owner
• [ ] Build a data map / record of processing — a database or diagram, not a memory — capturing purpose of use, sharing, storage location, retention period, transfers, point of collection, and every third party with access
• [ ] At the very least, ensure the privacy office can state which categories the business collects and where each is collected and stored
• [ ] Keep the map current; it is the single source of truth for notices, consumer-rights responses, breach analysis, and minimization

You cannot protect, govern, or lawfully delete data you cannot find. That sentence is the whole justification for doing the data map first — before a single policy paragraph is drafted — and it is also why the map is the phase most programs skimp on. A complete data inventory is genuinely laborious. It requires interviewing every team, chasing shadow IT, and cataloging the marketing platform that someone stood up with a corporate card three years ago. Because the work is unglamorous and slow, many programs quietly declare the map "in progress" and move on to the fun part, which is writing rules. This is exactly backward. The rules are only as good as the inventory beneath them.

The payoff is concrete and arrives on the worst day. When a deletion request lands, the difference between honoring it within a week and flailing for a month is whether someone already knew that a given customer's data lives in the production database, a nightly backup, an analytics warehouse, a customer-support tool, an email-marketing platform, and a spreadsheet on a regional manager's laptop. The map turns "we think we got all of it" into "here is the list of systems we checked." One of those is a defense; the other is a confession.

Sensitive categories deserve their own column and their own alarm. Tidewater's map should flag, in red, the wearable's precise-geolocation stream, the sleep-and-activity data that reads as health information under several regimes, the payment data governed by contract and by the card networks, and — most dangerous of all — the Tidewater Junior data, which is children's information and triggers a separate statutory scheme entirely. The map is also where you discover the surprises: the "anonymous" analytics that turn out to be keyed to a persistent device identifier, the free-text support field where customers occasionally paste their prescriptions, the recruiting inbox full of applicant resumes nobody classified.

Trap: treating the map as a one-time project rather than a living asset. A data map captured in Q1 and never touched again is a historical document by Q3. Wire an update trigger into the change-management process: any new data source, new vendor, or new processing purpose updates the map before it goes live. The map feeds directly into minimization — you cannot reduce what you have never counted — a discipline UpLaw covers in depth in its guide to data minimization and storage limitation.

Phase 3 — Read the Patchwork

• [ ] Treat FTC Section 5 (15 U.S.C. § 45) as the federal floor: your public privacy promises are legally enforceable, and inadequate data security is independently actionable as an unfair practice
• [ ] Assess CCPA/CPRA coverage against its thresholds and map its consumer rights, its sensitive-personal-information category, and its private right of action for certain breaches
• [ ] Survey the growing roster of comprehensive state statutes — roughly twenty as of early 2026 — with their controller/processor architecture, opt-out rights, and data-protection-assessment duties
• [ ] Assess GDPR reach (offering goods or services to, or monitoring, people in the EU) and its lawful-basis, accountability, breach-notice, DPIA, and transfer rules
• [ ] Identify applicable sectoral statutes: HIPAA, GLBA and the Safeguards Rule, COPPA, the FCRA, and state biometric laws such as Illinois's BIPA
• [ ] Adopt the design rule: build to the strictest applicable standard for each obligation, then apply it broadly

There is no comprehensive federal privacy law in the United States. Read that sentence twice, because most of the program's complexity descends from it. In the absence of a single national statute, compliance means holding a dozen partially overlapping, occasionally contradictory regimes in your head at once — and the program is, in large part, the institutional machinery for surviving that patchwork without losing your mind. This phase is where you draw the map of which laws reach your company; the rest of the program is the response.

The federal baseline: FTC Section 5

Section 5 of the Federal Trade Commission Act, 15 U.S.C. § 45, prohibits "unfair or deceptive acts or practices in or affecting commerce." Those two words carry enormous weight in privacy. A practice is deceptive when a company says one thing and does another — most commonly, when its privacy policy promises protections the company does not actually deliver. A practice is unfair when it causes substantial consumer injury that consumers cannot reasonably avoid and that is not outweighed by countervailing benefits. The FTC has used the unfairness prong to police data security itself, on the theory that failing to maintain reasonable safeguards is an unfair practice regardless of what the privacy policy says.

The leading authority is FTC v. Wyndham Worldwide Corp., 799 F.3d 236 (3d Cir. 2015), where the Third Circuit confirmed that the Commission's unfairness authority extends to a company's cybersecurity practices and rejected the argument that Wyndham lacked fair notice of what the statute required. After three intrusions exposed hundreds of thousands of payment-card records, the FTC's theory was straightforward: a company that stored card data in clear text, used easily guessed passwords, and ran no meaningful monitoring had engaged in an unfair practice. The case is the reason "we never promised anything in our policy" is not a defense — the unfairness prong does not depend on a broken promise.

But the baseline has an edge that cuts the other way, and it is worth knowing. In LabMD, Inc. v. FTC, 894 F.3d 1221 (11th Cir. 2018), the Eleventh Circuit vacated an FTC data-security order as unenforceably vague. The order commanded LabMD to install a "reasonably designed" security program but never specified any concrete act the company had to perform or refrain from performing. The lesson for a program is double-edged: the FTC's authority is broad, but a remedy — and by extension a compliance obligation — has to be specific enough to be followed. "Be reasonable" is a standard, not an instruction. Your program's job is to convert the standard into instructions.

California as the national floor

The California Consumer Privacy Act, Cal. Civ. Code § 1798.100 et seq., as amended by the California Privacy Rights Act (CPRA), functions as a de facto national standard for one dull commercial reason: it is easier to give every U.S. customer California-grade rights than to build a fifty-state switchboard that hands Californians one experience and everyone else another. Coverage turns on thresholds — a business generally falls in scope if it has annual gross revenue above $25 million (adjusted for inflation), buys, sells, or shares the personal information of 100,000 or more California consumers or households, or derives 50% or more of its annual revenue from selling or sharing personal information. Tidewater, at scale, clears the revenue threshold on its own.

The CCPA grants California consumers rights to know, delete, correct, and opt out of the sale or sharing of their personal information, plus a heightened tier of protection for sensitive personal information — a category that reaches precise geolocation, health data, and more, precisely the data Tidewater's wearable generates. The provision that keeps general counsel awake is the private right of action at Cal. Civ. Code § 1798.150, which lets consumers sue over a breach of nonencrypted and nonredacted personal information caused by a failure to maintain reasonable security, and recover statutory damages of between $100 and $750 per consumer per incident — before any showing of actual harm. Multiply $750 by a six-figure breach and the number that results is why encryption, discussed in Phase 5, is not optional. Regulatory penalties run separately: the California Privacy Protection Agency (CPPA) and the Attorney General can seek civil penalties of up to $2,500 per violation, rising to $7,500 for intentional violations or violations involving minors' data (Cal. Civ. Code § 1798.155).

The state wave

California was the first mover, not the last word. Roughly twenty states have enacted comprehensive consumer-privacy statutes as of early 2026 — Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, and a still-lengthening list — and most of them share a common architecture borrowed from the GDPR rather than from California. They speak in terms of controllers (who decide the purposes and means of processing) and processors (who process on a controller's behalf), grant access, deletion, correction, and portability rights, provide opt-outs for targeted advertising, sale, and certain profiling, and require data protection assessments for higher-risk processing.

The trap is assuming that "we comply with California" means "we comply everywhere." It does not. Thresholds differ, definitions of "sale" differ, cure periods differ (several states are sunsetting the right to cure a violation before enforcement), and the sensitive-data rules differ — some states require opt-in consent for sensitive data where California uses an opt-out. A program that hard-codes California's exact rules will misfire in Colorado and Connecticut. The workable design is to build to the union of obligations — grant the broadest set of rights, honor the strictest consent posture — rather than to any single statute. That is the design rule below, stated in advance.

The GDPR's long arm

The GDPR reaches far past the EU's borders. Article 3 extends the regulation to controllers and processors not established in the Union where they offer goods or services to people in the EU or monitor their behavior. Tidewater ships meal kits to Berlin and streams a Berliner's sleep data back to a U.S. server; both hooks are set. Once the GDPR applies, it brings its own demanding apparatus: a lawful basis for every processing activity (Art. 6) — consent, contract, legal obligation, vital interests, public task, or legitimate interests, and no processing without one; the transparency and notice duties of Articles 13 and 14; the accountability principle of Article 5(2), which requires not just compliance but the ability to demonstrate compliance; breach notification to the supervisory authority within 72 hours (Art. 33); data protection impact assessments for high-risk processing (Art. 35); and strict rules on transferring personal data out of the EU.

That last item is its own discipline. After the Court of Justice invalidated the Privacy Shield in Schrems II, cross-border transfers to the United States have run on Standard Contractual Clauses backed by transfer impact assessments and, more recently, the EU–U.S. Data Privacy Framework. Tidewater's routine act of storing an EU customer's data on U.S. cloud infrastructure is a regulated transfer that needs a lawful mechanism — a subject UpLaw treats in full in its article on moving personal data out of the EU after Schrems II. Many companies with no EU obligations still build to GDPR standards as a matter of strategy, because a program that satisfies the GDPR generally clears the lower bars set by U.S. state law almost as a byproduct.

The sectoral overlay

On top of the general laws sit the sector-specific statutes, and they do not care that you already built a general program. Five recur often enough to check every time:

• HIPAA. The Health Insurance Portability and Accountability Act governs protected health information held by covered entities and their business associates, at 45 C.F.R. Parts 160 and 164, including the business-associate-agreement requirements of § 164.504(e). Tidewater is probably not a covered entity — it is not a health plan, clearinghouse, or covered provider — but the moment it partners with a telehealth provider or a health plan, it can slide into business-associate status and inherit HIPAA obligations by contract. The cloud dimension of that analysis is covered in UpLaw's guide to HIPAA in the cloud.
• GLBA and the Safeguards Rule. The Gramm-Leach-Bliley Act governs nonpublic personal information held by financial institutions, and the FTC's amended Safeguards Rule, 16 C.F.R. Part 314, imposes specific administrative, technical, and physical safeguard requirements — including a designated qualified individual, a written risk assessment, encryption, and access controls. The definition of "financial institution" is broader than banks; companies that extend credit or facilitate payments have been surprised to find themselves inside it.
• COPPA. The Children's Online Privacy Protection Act, 15 U.S.C. §§ 6501–6506, and the FTC's implementing rule at 16 C.F.R. Part 312, govern the online collection of personal information from children under 13 and require verifiable parental consent before collection (see 16 C.F.R. § 312.5). Tidewater Junior detonates this obligation. If the nutrition tracker is directed to children or the company has actual knowledge that it collects data from under-13 users, it needs a COPPA-compliant consent flow, a children's privacy notice, and strict limits on retention and disclosure — a mistake here draws FTC penalties measured per child.
• FCRA. The Fair Credit Reporting Act governs consumer reports and the entities that furnish, use, or assemble them; companies that make eligibility decisions using third-party data can find themselves regulated as users or even as consumer reporting agencies.
• State biometric law. Illinois's Biometric Information Privacy Act, 740 ILCS 14, is the sharpest of these, requiring informed written consent before collecting biometric identifiers and providing a private right of action with statutory damages that have driven nine-figure settlements. If Tidewater's wearable derives biometric identifiers from any Illinois user, BIPA is in play. UpLaw's article on biometric privacy law and the AI systems that read faces and voices maps this terrain, and its overview of key legal issues in artificial intelligence situates it within the broader AI-governance picture.

The design rule

Staring at that overlapping thicket, the temptation is to build a bespoke response for each law. Resist it. The rule that keeps a program sane is: for each discrete obligation, identify the strictest standard that any applicable law imposes, meet that standard, and apply it broadly. If Colorado requires opt-in consent for sensitive data and California requires only opt-out, build the opt-in flow and give it to everyone. If the GDPR demands a lawful basis and a U.S. state does not, document a lawful basis anyway. Uniform, strictest-standard design costs more up front and vastly less over time, because the alternative — a per-jurisdiction switchboard of subtly different experiences — is a maintenance nightmare that breaks silently every time a law changes.

Phase 4 — Anchor to a Framework and Sequence the Work

• [ ] Anchor the program to neutral, law-agnostic frameworks: the Fair Information Practice Principles (FIPPs) and the NIST Privacy Framework
• [ ] Build a compliance roadmap for the next 6–12 months, prioritized by risk to be mitigated, cost to implement, and speed or ease of achievement
• [ ] Attack high-risk items and easy wins first; consciously defer expensive, low-risk, hard items
• [ ] Revisit the roadmap on a fixed cadence — roughly every six months

If you build your program to the exact contours of today's laws, you will be rebuilding it constantly, because the laws move. The more durable approach is to anchor the program to a neutral framework whose principles map onto every regime, so the program bends gracefully as statutes change rather than shattering and needing reconstruction. Two frameworks do this work.

The Fair Information Practice Principles are the intellectual DNA of nearly every modern privacy law on earth: notice, choice, purpose limitation, data minimization, accuracy, security, access, and accountability. Trace any provision of the GDPR or a state statute back far enough and you arrive at a FIPP. Building to the principles rather than to any one statute's phrasing means the program already speaks the language the next law will be written in.

The NIST Privacy Framework translates those principles into an operational structure organized around five functions — Identify, Govern, Control, Communicate, and Protect — that dovetails with the widely used NIST Cybersecurity Framework, which matters because privacy and security share so much plumbing. Using NIST gives the program a common vocabulary with the security team and a maturity model to measure progress against.

With an anchor chosen, the roadmap converts analysis into action. A roadmap is nothing more than a prioritized list of the gaps between where the program is and where it needs to be, sequenced by three variables: how much risk closing the gap removes, how much it costs, and how quickly it can be done. Attack the high-risk items and the cheap easy wins first; consciously defer the expensive, low-risk, hard items. The classic error is priority inversion: a company spends three months perfecting the aesthetics of its cookie banner while an unencrypted database of Social Security numbers sits untouched, because the banner is visible and the database is not. The roadmap exists to force that comparison into the open.

The roadmap also does quiet legal work. When a regulator comes calling, a dated, risk-ranked roadmap showing that the company identified its gaps and was methodically closing them is often the difference between a warning letter and a penalty. It converts the company's posture from "we had no idea" to "we knew, we prioritized, and here is the evidence we were acting in good faith." Revisit it on a fixed cadence, because the data, the vendors, the technology, and the law will all have moved since you drew it.

Phase 5 — Build the Operating Machinery

This is the phase where the program stops being a plan and starts being a set of things that run every day. Each subsection is a machine that has to work not once but continuously, and each has a failure mode that regulators and plaintiffs know to look for.

Privacy notices that match reality

• [ ] Draft accurate privacy notices for every surface — website, mobile app, offline, and employee-facing — reconciled line by line against the data map
• [ ] Include the mandatory content each applicable law requires (the CCPA notice-at-collection elements; GDPR Articles 13–14 disclosures) and the "Do Not Sell or Share My Personal Information" link where the CCPA applies
• [ ] Reconcile the notice against actual practice before publishing, and re-reconcile whenever practice changes

A privacy notice is not marketing copy; under Section 5 it is a legally enforceable promise, and a beautiful notice describing practices the company does not actually follow is worse than no notice at all. It manufactures the exact deception the FTC exists to punish. The cardinal rule is that the notice describes what the company does, which is why it can only be drafted after the data map exists. Tidewater cannot honestly say "we do not sell your data" until someone has confirmed, against the map, that no arrangement with an ad-tech vendor meets the sprawling statutory definition of "sale." Many companies discover, doing this reconciliation, that their pixel-based advertising is a "sale" or "sharing" under the CCPA — and that their notice has been quietly false for two years.

The consumer-rights (DSAR) pipeline

• [ ] Build a data subject access request (DSAR) / consumer-rights process: recognized intake channels, identity verification proportionate to the sensitivity of the data, a reliable way to find the requester's data across every system on the map, correct application of exemptions, and a log of every request and its disposition
• [ ] Meet the response clocks each law sets (the GDPR's one-month baseline under Article 12; the CCPA's 45-day window, extendable once)
• [ ] Test the pipeline against volume before you need it

The rights pipeline is the program's public stress test. When a consumer exercises a right — to access, delete, correct, or opt out — the company has a hard deadline and a legal duty to answer completely. A deletion request the company cannot fully honor is not an awkward gap; it is a documented violation, memorialized in the very request log the law encourages you to keep. And a process that works fine for ten requests a month collapses under a thousand, which is what happens the week after a data-broker opt-out campaign or a viral complaint. Article 12 of the GDPR spells out the mechanics — the controller must respond without undue delay and within one month, may extend by two further months for complex requests, and must generally act free of charge — and the state statutes set their own comparable clocks.

The verification step is a genuine tension, not a formality. Verify too little and you hand a stalker or a fraudster the victim's file; verify too much and you deny legitimate requesters their rights and create your own violation. The pipeline has to find a proportionate middle, calibrated to how sensitive the requested data is. This machinery is exactly why the data map came first: a DSAR is only answerable if you already know every place the requester's data lives.

Vendors and data processing agreements

• [ ] Maintain a vendor inventory and conduct privacy and security due diligence before onboarding any processor
• [ ] Put a data processing agreement (DPA) in place with every processor — satisfying GDPR Article 28's mandatory terms, the state controller/processor requirements, and, where PHI is involved, a HIPAA business associate agreement under 45 C.F.R. § 164.504(e)
• [ ] Monitor vendors during the relationship and offboard them cleanly, with documented return or deletion of data

Vendors are a leading source of privacy risk, for the simple reason that your data is only as protected as the least careful company you hand it to. A large share of the most damaging incidents originate not in the company's own systems but in a vendor's — the analytics provider that got breached, the email platform that mis-configured a bucket, the offshore support contractor who exported a customer list. Diligence before onboarding is the cheapest control in the whole program; unwinding a bad vendor relationship after a breach is among the most expensive.

The DPA is the contractual instrument that carries the obligations downstream. GDPR Article 28 prescribes a list of terms every processor contract must contain: the processor acts only on documented instructions, ensures the confidentiality of personnel, implements appropriate security, engages sub-processors only with authorization, assists the controller with data-subject requests and breach notification, and deletes or returns the data at the end of the engagement. State laws impose analogous controller/processor terms, and HIPAA requires the business associate agreement with its own mandatory contents. Tidewater's map might list forty vendors; every one that touches personal data needs the right paper, and the offboarding clause matters as much as the onboarding one — data left behind in a decommissioned vendor's systems is a breach waiting for a headline.

DPIAs and privacy by design

• [ ] Institute data protection impact assessments (DPIAs) for higher-risk processing — GDPR Article 35, plus the state data-protection-assessment triggers for targeted advertising, sale, sensitive-data processing, and certain profiling
• [ ] Embed privacy by design and by default (GDPR Article 25) so that privacy review happens at the start of a project, not as a last-minute gate

The DPIA is a structured pre-mortem: before launching a processing activity likely to result in high risk to the rights and freedoms of individuals, the company documents what data it will use, why, what could go wrong, and what safeguards reduce the risk. Article 35 of the GDPR makes it mandatory for high-risk processing — large-scale monitoring, sensitive-data processing at scale, systematic profiling — and the newer state statutes require parallel "data protection assessments" for a defined set of high-risk activities. The assessment's real value is not the document it produces but the timing it forces: it drags the privacy team into the room at the beginning of a project, when the design can still change, rather than at the end, when the only options are ship-with-risk or blow the deadline.

That timing is the essence of privacy by design, codified at GDPR Article 25 and increasingly expected everywhere. If Tidewater runs a DPIA before wiring the wearable's location stream into a new feature, it can build data minimization and access controls into the architecture. If it runs the DPIA after launch, it is writing an incident report. For a data-heavy product like a mobile app, this discipline is central to the whole compliance picture — see UpLaw's compliance map for mobile app privacy law and its practical checklist for launching a mobile app.

Security safeguards and the breach playbook

• [ ] Coordinate concrete security safeguards with the security team: access controls on a least-privilege basis, encryption at rest and in transit, logging, and monitoring
• [ ] Stand up a written, tested, and rehearsed incident-response plan keyed to the actual notification clocks that apply (the GDPR's 72 hours; the fifty state breach-notification statutes; HIPAA and GLBA)
• [ ] Pre-position the response team, outside counsel, forensic firm, and notification templates before the incident, not during it

Privacy and security are different disciplines that fail together. The privacy program does not own the firewall, but it owns the consequences of the firewall failing, so the two functions have to be joined at the hip. Encryption earns a special mention because it is the rare control that carries a literal legal safe harbor: several breach-notification regimes, including California's at Cal. Civ. Code § 1798.82, treat the loss of properly encrypted data as effectively no breach at all, and the CCPA's private right of action reaches only nonencrypted and nonredacted personal information. Encrypt the database of Social Security numbers and a stolen backup becomes a non-event; leave it in clear text and the same theft becomes a class action at $750 a head.

The incident-response plan is where preparation pays for itself many times over. A breach is a clock-driven crisis: the GDPR gives 72 hours to notify the supervisory authority, every U.S. state sets its own timing and content rules for notifying residents (and often a state agency), and the sectoral laws add their own. A plan that lives in a binder no one has opened is not a plan; it is a prop. The plan has to be rehearsed — tabletop exercises, a named incident commander, pre-drafted notification templates, a forensic firm on retainer, and outside counsel engaged early to preserve privilege over the investigation. That privilege point is subtle and often botched: forensic reports written the wrong way become discoverable roadmaps for the plaintiff. UpLaw's resources on folding IP and evidence preservation into breach response — the article on protecting trade secrets during a data breach and the companion trade secret incident-response checklist — cover the privilege and preservation traps in detail.

Training

• [ ] Deliver privacy training at least annually, with role-specific modules for employees who handle sensitive data, build products, or manage vendors
• [ ] Track completion and refresh the content as the program and the law change

The best-designed program fails at the point of a careless click. Training is the control that reaches the humans — the support agent who wants to be helpful and emails a customer's full file to the wrong address, the engineer who copies a production database to a laptop for "convenience," the marketer who buys a list of dubious provenance. General annual training sets the floor; role-specific training does the real work, because the risks a recruiter faces differ from those a data engineer faces. Track completion, because "we trained everyone" is only a defense if you can prove it — which brings the whole program back to documentation.

Retention and minimization

• [ ] Enforce a records-retention schedule with defined retention periods per data category and automated deletion or de-identification at the end of each period
• [ ] Practice data minimization at collection — gather only what a defined purpose requires — so the program shrinks the surface it has to defend

Data you have already lawfully deleted cannot be breached, cannot be subpoenaed, and cannot be the subject of a deletion request. That single sentence is the entire business case for retention discipline. Over-retention is the slow, invisible way a company enlarges every category of risk at once: a bigger breach surface, a bigger litigation and e-discovery surface, a bigger DSAR surface. The old instinct to keep everything forever "just in case" is, under modern privacy law, an instinct to accumulate liability. Minimization attacks the problem at the front door — collect less — and retention schedules attack it at the back — keep it for less time. Together they are the cheapest risk reduction available, because the safest data is the data you never held or already destroyed. UpLaw's data minimization guide works through the retention-schedule and defensible-deletion mechanics in full.

Phase 6 — Prove It: Documentation, Monitoring, and Audit

• [ ] Maintain the documentation spine: the data map, risk assessments and DPIAs, privacy notices with their version history, training records, vendor agreements and the vendor inventory, the DSAR log, the incident-response plan, records of any incidents and how they were handled, and — where the GDPR applies — the Article 30 record of processing activities
• [ ] Conduct periodic audits with genuine independence from the day-to-day program, benchmarking reality against the roadmap and feeding every gap back into the next cycle
• [ ] Evaluate and revise controls continually, because the data, the vendors, the technology, and the law never stop moving

A program that works perfectly but cannot demonstrate that it works is, from a regulator's chair, indistinguishable from a program that does nothing. This is the accountability principle stated bluntly, and it is why documentation is not bureaucratic busywork — it is the program's evidentiary spine. When a regulator inquires, a plaintiff sues, or the board asks for assurance, documentation is the machine that converts "we tried" into "here is the dated, contemporaneous evidence." The GDPR makes this explicit in Article 5(2)'s accountability principle and Article 30's record-of-processing requirement, but the logic is universal: undocumented compliance is, evidentially, no compliance at all.

Audit supplies the independent check. A program that grades its own homework drifts, because the people who built a control are the last to notice it has quietly stopped working. Periodic review by someone outside the day-to-day program — internal audit, or an outside assessor — benchmarks what the program actually does against what the roadmap says it should do, and every gap it finds becomes an input to the next roadmap cycle. The result is a loop, not a finish line. A privacy program is less like a building you complete and hand over than like a garden you tend: leave it alone and it does not stay finished; it reverts.

Common Failure Modes

The same handful of mistakes sink real programs. Each is worth naming because each is avoidable.

• Confusing a policy with a program. A polished privacy policy with no operational program behind it does not reduce risk; it manufactures risk, because it converts an operational gap into a Section 5 deception. The document promises what the missing program cannot deliver.
• Naming "everyone" as responsible. Diffuse accountability is no accountability. Without a named owner vested with real authority, decisions default to the fastest-moving team, which is never the privacy team.
• Skipping the data map. Every downstream failure — the unanswerable DSAR, the incomplete breach notice, the false privacy notice — traces back to not knowing what data the company holds and where it lives.
• Hard-coding one state's rules. Building the whole program to California and assuming it covers Colorado, Virginia, or the GDPR guarantees a misfire the first time a stricter rule applies.
• Letting the notice drift from practice. Privacy notices and actual data flows drift apart silently as products change; the drift is invisible until a regulator or plaintiff lines the two up side by side.
• Treating breach response as a document. An incident-response plan that has never been rehearsed is a prop. The clocks — 72 hours under the GDPR, days under the state statutes — do not pause while the team figures out who to call.
• Over-retaining data. Keeping everything forever enlarges the breach, litigation, subpoena, and DSAR surfaces simultaneously. Dormant data is not a neutral asset; it is a standing liability.

A Ninety-Day Starting Sequence

For a company beginning from zero, the sheer scope of the program can induce paralysis. It should not. The work sequences naturally, and a disciplined first quarter puts the foundation in place.

Days 1–30: name the owner and start the map. Secure the senior sponsor and board acknowledgment, appoint the accountable privacy lead, and charter the cross-functional liaisons. In parallel, begin the data-mapping interviews. The map will not finish in thirty days, but the highest-risk categories — payment data, health-adjacent data, children's data, biometrics — should be identified and flagged first.

Days 31–60: read the patchwork and reconcile the notice. With the map's high-risk categories in hand, run the coverage analysis: which laws reach the company, and where. Reconcile the existing privacy notice against actual practice and fix the discrepancies, because a false notice is the most immediately actionable exposure a company carries. Stand up a basic, working DSAR intake channel even before the pipeline is polished — a request you cannot receive is worse than one you answer imperfectly.

Days 61–90: sequence the roadmap and close the fastest gaps. Choose the NIST/FIPPs anchor, draft the risk-ranked roadmap, and knock out the cheap high-value fixes — encrypting the sensitive database, papering the vendors that lack a DPA, standing up the retention schedule for the riskiest data, scheduling the first training. End the quarter with a documented roadmap, because that document is both the plan for the next quarter and the good-faith evidence that protects the company while the rest of the program is built.

None of this makes the company "done." It makes the company underway, with an owner, a map, a legal read, an anchor, a plan, and a paper trail — which is precisely the posture that turns a bad day into a manageable one.

Primary Authority

• Federal baseline. FTC Act § 5, 15 U.S.C. § 45; FTC v. Wyndham Worldwide Corp., 799 F.3d 236 (3d Cir. 2015) (unfairness authority reaches data security); LabMD, Inc. v. FTC, 894 F.3d 1221 (11th Cir. 2018) (data-security order must be specific, not merely "reasonable").
• California. California Consumer Privacy Act, Cal. Civ. Code § 1798.100 et seq., as amended by the CPRA; private right of action and statutory damages of $100–$750 per consumer per incident, Cal. Civ. Code § 1798.150; civil penalties, Cal. Civ. Code § 1798.155; breach-notification and encryption safe harbor, Cal. Civ. Code § 1798.82; enforcement by the California Privacy Protection Agency.
• Other state comprehensive statutes. Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, and a growing roster (roughly twenty as of early 2026), sharing a controller/processor architecture with access, deletion, correction, and portability rights, opt-outs, and data-protection-assessment duties. Verify the current count and each state's thresholds, definitions, and cure provisions at official sources.
• European Union. General Data Protection Regulation, Regulation (EU) 2016/679, Arts. 3 (territorial scope), 5 (principles, including accountability), 6 (lawful basis), 12–14 (transparency and DSAR mechanics), 25 (data protection by design and by default), 28 (processor contracts), 30 (records of processing), 33–34 (breach notification), 35 (DPIA), 37–39 (DPO).
• Sectoral. HIPAA, 45 C.F.R. Parts 160 and 164, including § 164.504(e) (business associate agreements); GLBA and the FTC Safeguards Rule, 16 C.F.R. Part 314; COPPA, 15 U.S.C. §§ 6501–6506 and 16 C.F.R. Part 312, including § 312.5 (verifiable parental consent); the Fair Credit Reporting Act; and state biometric statutes, notably the Illinois Biometric Information Privacy Act, 740 ILCS 14.
• Frameworks. Fair Information Practice Principles; NIST Privacy Framework (Identify, Govern, Control, Communicate, Protect).

Privacy law changes faster than almost any other field of commercial regulation. Verify current thresholds, deadlines, statutory-damage figures, and the running count of state laws against official sources before relying on any of them.

Related UpLaw Resources

Related Guides

• Building a Privacy Compliance Program: Governance, Data Mapping, and the Legal Patchwork — the narrative companion to this checklist.
• Data Minimization and Storage Limitation: Curbing the Over-Retention of Personal Data — retention schedules and defensible deletion in depth.
• Mobile App Privacy Law: A Compliance Map for Founders and Counsel — the same patchwork applied to a data-heavy app.
• HIPAA in the Cloud: Business Associates, BAAs, and Protecting ePHI — when health data pulls you into HIPAA.

Related Checklists

• Launching a Mobile App: A Practical Legal Checklist — the privacy step inside a broader launch workflow.
• Standing Up a Trade Secret Protection Program: A Practical Checklist — the parallel program-building discipline for confidential information.
• When a Breach Hits Your Crown Jewels: A Trade Secret Incident-Response Checklist — folding IP preservation into breach response.
• CAN-SPAM Compliance for Commercial Email: A Practical Checklist — the marketing-data corner of the program.
• Drafting an Employee Handbook That Holds Up: A Practical Checklist — where employee-data policies live.

Related Toolkits

• The Privacy and Data Protection Toolkit: Building and Operating a Compliance Program — the full life-cycle resource library.
• AI and Emerging Technology Law: A Roadmap and Resource Toolkit — where privacy meets AI governance.

Related Articles

• Moving Personal Data Out of the EU After Schrems II: SCCs and Transfer Impact Assessments — the cross-border-transfer machinery.
• Biometric Privacy Law and the AI Systems That Read Faces and Voices — BIPA and the wearable/biometric exposure.
• Protecting Trade Secrets During a Data Breach: Building IP Into Incident Response — privilege and preservation in a breach.
• Key Legal Issues in Artificial Intelligence: A Comprehensive Guide for Business and Counsel — privacy inside the wider AI-risk picture.
• Cameras, Consent, and the Law of Recording People — consent and expectation-of-privacy doctrine at the edges of data collection.

---

This checklist is general legal information, not legal advice. Privacy law varies by jurisdiction and changes rapidly, and applying any statute, regulation, or case to your specific facts requires the judgment of qualified counsel. Consult a licensed attorney before making decisions about your privacy compliance program.