A 90-Day Privacy Program for Startups

Ninety days is enough time to build a real, defensible privacy program for a startup — not a complete one, but a genuinely functioning one: you will know what personal data you hold, have a basis for processing it, know how to handle a request or a breach, and have your riskiest vendor gaps closed. Here is a phase-by-phase plan to get there with named owners and concrete outputs, assuming a small team where the same two or three people wear most of the hats.

Why a fixed timeline works better than an open-ended one

Privacy work at a startup competes with everything else on the roadmap and will always lose that fight if it has no deadline of its own. A 90-day plan works because it is short enough to stay a priority, long enough to produce something real, and structured enough that "we'll get to it eventually" is no longer an option. The output at day 90 should be a program a new hire, an auditor, or an enterprise customer's security questionnaire could actually be pointed at.

Phase 1: Days 1–30 — See what you actually have

Owner: whoever is accountable for privacy (often the founder, COO, or first compliance/security hire).

• Week 1–2: Build the data inventory. Map every system that touches personal data — product database, CRM, support tool, HR system, analytics, marketing tools, AI tools — and for each, what data it holds, why, and who can access it. Use the data inventory and RoPA starter kit rather than starting from a blank sheet; most of the structure is reusable.
• Week 2–3: Identify lawful basis and purpose for each major processing activity. For each row in the inventory, write one sentence on why you collect it and what basis you're relying on. Gaps here (data you collect but can't explain) become your first cleanup list.
• Week 3–4: Inventory vendors and check contracts. List every processor that touches personal data (cloud hosting, email, analytics, AI tools, payroll). Confirm a data processing agreement exists for each; if you have none, that is priority work for phase 2. The vendor privacy assessment template gives you a consistent way to evaluate each one.

Output by day 30: a maintained data inventory, a purpose/basis note per major system, and a vendor list with contract status flagged red/amber/green.

Phase 2: Days 31–60 — Fix the highest-risk gaps and build the core policies

Owner: privacy/compliance lead, with input from engineering and whoever handles customer/HR data day to day.

• Week 5–6: Close the reddest vendor gaps. Get DPAs signed with any processor missing one, starting with whichever handles the most sensitive data or the largest volume.
• Week 6–7: Write the core policies your business actually needs — an external privacy notice that reflects what phase 1 found (not a template copied from a competitor), an internal data handling/acceptable-use policy, and a breach response plan. Draft against the data breach response checklist so the plan has concrete steps, not just intentions.
• Week 7–8: Stand up a request-handling process. Decide who receives a data subject access, deletion or correction request, what the internal steps are, and what your response deadline is. This does not need special tooling at a small company — a documented process and a shared inbox is a legitimate starting point.

Output by day 60: signed DPAs for high-risk vendors, a published privacy notice, an internal handling policy, a breach response plan, and a working request-handling process (tested at least once internally).

Phase 3: Days 61–90 — Train, test and make it stick

Owner: privacy/compliance lead, with visible sponsorship from leadership.

• Week 9–10: Run a lightweight training session for the whole company, not a compliance-theatre video nobody watches. Cover what data classes exist, what tools are approved for what, and who to contact with questions or concerns. Anyone using AI tools with company data should hear specifically about acceptable use here.
• Week 10–11: Tabletop-test the breach response plan. Walk through a realistic scenario (a vendor emails you about a leaked customer list) and see whether the plan actually works when someone follows it under mild pressure. Fix what breaks.
• Week 11–12: Set a maintenance cadence. Decide who reviews the inventory and vendor list, and how often (quarterly is reasonable for a startup). A program that isn't revisited decays within two quarters.

Output by day 90: a trained team, a tested breach response plan, and a scheduled review cadence — the difference between a program and a project.

A simple way to track it

A single tracking sheet with these columns keeps the plan honest without needing project management software:

What "good enough" looks like at a startup

Startups sometimes stall this work waiting to build something as thorough as what a large enterprise has. That is the wrong bar for day 90. Good enough at 90 days means: you can name every system with personal data and why it's there, every high-risk vendor has a signed DPA, you have a privacy notice that reflects reality rather than a template, someone knows what to do in the first hour of a suspected breach, and there's a date on the calendar for the next review. That is a defensible, genuinely functioning program — refinement (formal risk assessments, DPIA processes, more granular access controls) is appropriate follow-on work for the next two quarters, not a prerequisite for calling day 90 a success.

A realistic example

A 25-person B2B SaaS startup preparing for its first enterprise security questionnaire ran this plan with a part-time compliance lead and two hours a week from engineering. The data inventory phase revealed the product used three analytics tools nobody had reviewed, one of which had no DPA and was sending user emails to a subprocessor with no documented safeguard. That got fixed in phase 2 before the enterprise deal's security review, which asked directly about subprocessors. By day 90, the company could answer a security questionnaire with an actual inventory and named policies instead of promises to "look into it," which shortened the sales cycle rather than stalling it.

Common failure modes

• Starting with policy-writing instead of the inventory. A privacy notice written before you know what data you actually hold is fiction with a nice layout.
• No single owner. Diffuse responsibility across founders "who'll get to it" reliably produces nothing by day 90.
• Treating training as a checkbox. A recorded video with no engagement teaches nobody anything and leaves the same gaps discovery would find later.
• Skipping the review cadence. Ninety days of good work with no maintenance plan degrades within two quarters as new tools and vendors get added without going through the process.

Do this next

• Assign a named owner for the 90 days, even if privacy is not their full-time job.
• Start the data inventory this week using the starter kit — don't wait for a "clean" starting point.
• Pull your current vendor list and run it against the vendor privacy assessment template.
• Print or bookmark the 90-day privacy program roadmap as a companion tracker for this plan.
• For the underlying concepts behind each phase — lawful basis, DPAs, breach response, subject rights — the global data privacy fundamentals course and practical privacy program implementation course cover them in the depth a 90-day sprint doesn't have time for, and the assessment is a fast way to see which phase your organisation should start from if you're not starting at zero.