slug: set-up-saas-privacy-policy title: How to Set Up a SaaS Privacy Policy (Founder Playbook) metaDescription: A 90-minute founder playbook to ship a SaaS privacy policy that satisfies GDPR, CCPA, and India's DPDP Act, with a real sub-processor list. excerpt: Ship a SaaS privacy policy in 90 minutes that holds up under GDPR, CCPA, and DPDP, with a named sub-processor list and an honest call on when to skip the generator and pay a lawyer.

How to Set Up a Privacy Policy for a SaaS

To set up a SaaS privacy policy in 2026, list every piece of personal data you touch, name your sub-processors (Stripe, Resend, AWS, your Postgres host), publish the rights you grant under GDPR, CCPA/CPRA, and India's DPDP Act, and ship it on a /privacy URL before you take your first paid signup. The 90-minute version uses Termly or Iubenda. The "we sell to enterprise" version costs about $2,000 with a privacy lawyer.

This is operational guidance, not legal advice. A real privacy lawyer is the only person who can tell you whether your specific product is compliant. What follows is the playbook most early-stage SaaS founders can use to get to a defensible v1, then know when it's time to upgrade.

What a SaaS privacy policy actually is (and what it isn't)

A privacy policy is a notice. It explains what data you collect, why, how long you keep it, who you share it with, and what users can do about it. It is not a contract; users don't "accept" a privacy policy the way they accept your Terms of Service.

The two documents do different jobs. Your Terms of Service is the contract covering acceptable use, payment, and liability. Your privacy policy is the disclosure that satisfies GDPR Articles 13 and 14, CCPA Section 1798.130, and India's DPDP Act notice requirement. You need both, and they should link to each other from the footer of every page.

The policy lives at /privacy (or /privacy-policy), gets a footer link from every page, and shows up next to the consent checkbox on your signup form. If a user can give you data without seeing the link, you have a problem.

The three laws every SaaS founder must pretend apply

You probably won't choose your jurisdiction. Stripe will route an EU card before you finish your coffee, a curious developer in California will sign up the same day, and an Indian recruiter will pitch your product to an enterprise within a month. Pretend all three regimes apply from day one.

GDPR (EU and UK)

GDPR Article 13 lists exactly what your policy must contain when you collect data directly from a user: identity of the controller, contact for the data protection officer, purposes and legal basis, recipients (your sub-processors), retention period, and the rights to access, rectify, erase, restrict, port, and object. Article 14 covers the same for data you collect indirectly.

Two clocks matter: a 72-hour breach notification window to the supervisory authority, and a 30-day default for responding to data subject requests. Both feel impossibly tight until you have a runbook.

CCPA and CPRA (California)

CCPA applies if you have $25M+ in annual revenue, process 100,000+ California consumers' data, or derive 50%+ of revenue from selling consumer data. Most pre-Series-A SaaS companies are technically out of scope. Almost all of them write a CCPA section anyway, because their first enterprise customer's procurement team will ask.

The big disclosures: a "Do Not Sell or Share My Personal Information" link, the right to know, the right to delete, and a 45-day response window with a possible 45-day extension.

DPDP Act (India 2024, Rules 2025)

India's Digital Personal Data Protection Act passed in August 2023. The Rules were notified on November 13, 2025, with full implementation arriving on May 13, 2027. Your privacy notice must be in clear plain language, available in English or any of the 22 scheduled languages, and must list the personal data collected, the purpose, the rights of the Data Principal, and a contact point for grievances.

If you process Indian user data and you're not a tiny operator, you'll likely need to appoint a Data Protection Officer in 2026 or 2027. Plan for it.

The 11 sections every SaaS privacy policy needs

Every defensible policy hits these eleven blocks. Generators produce them in roughly this order; the cheap ones produce them poorly.

Identity of the controller and DPO contact
Categories of personal data (account, billing, product usage, support tickets, cookies, device data)
Purposes of processing and the legal basis under GDPR (consent, contract, legitimate interest)
Sub-processor list with named vendors
Data retention periods, by category
Data subject rights (access, deletion, portability, restriction, objection) and how to exercise them
International data transfers (Standard Contractual Clauses for EU, the UK IDTA, DPDP transfer rules)
Security overview (encryption, access controls, audit logging)
Cookies and similar technologies, with link to consent banner
Children's data
Effective date and changelog

Most generators get points 1, 2, 3, 9, and 11 right. Almost all of them fluff point 4, which is the section that actually matters when an enterprise procurement team reviews you.

Your sub-processor list is the section everyone forgets

This is the section that separates a real policy from a template. List every third party that touches user data, by name, with a one-line purpose and a link to their data processing addendum.

Here's what a typical early-stage SaaS list looks like:

Sub-processor	Purpose	Region	DPA link
Stripe	Payment processing	US, EU	stripe.com/legal/dpa
Resend	Transactional email	US	resend.com/legal/dpa
AWS (us-east-1)	Hosting + storage	US	aws.amazon.com/compliance/gdpr-center/
Vercel	Frontend hosting + edge	Global	vercel.com/legal/dpa
Supabase	Postgres + auth	EU (Frankfurt)	supabase.com/dpa
PostHog	Product analytics	EU (Frankfurt)	posthog.com/dpa
Linear	Customer support tickets	US	linear.app/dpa

Update it when you swap a vendor. The day you migrate from PostHog to Mixpanel, the line in the policy changes within 30 days. Enterprise security questionnaires explicitly ask for this list, and a vague "we use industry-standard analytics tools" answer will lose you a deal that took six months of sales work to land.

Pick a generator: Termly vs Iubenda vs lawyer

For an unvalidated MVP collecting email addresses on a waitlist, you don't need a $3,000 lawyer draft; a free generator output, lightly edited, is fine. For a B2B SaaS chasing a $50k annual contract, you do.

Approach	Cost	Time to ship	Best for	Honest downside
Termly free tier	$0	60 min	Pre-launch, waitlist, side projects	Watermark, generic categories, no sub-processor table
Termly Pro	$10 to $39/mo	60 min	Self-serve consumer SaaS, sub-$1M ARR	Still template-shaped; recurring cost
Iubenda	$27 to $99/yr per policy	90 min	EU-first products, multilingual rollouts	Per-policy upsells; UX feels dated
Cookiebot + Termly	$10 to $60/mo combined	2 hrs	Need granular consent + policy generator	Two tools to maintain
Privacy lawyer (flat fee)	$1,500 to $3,500	2 to 3 weeks	B2B selling to enterprise, healthcare, fintech	Slow, needs annual review

Termly's free tier covers 90% of the wording for a generic SaaS. Where it falls down is the sub-processor list and any sectoral requirement (HIPAA, PCI, GLBA). Iubenda is stronger if you're operating natively in three or more European languages. Cookiebot is the most reliable consent banner; pair it with Termly for the policy itself.

If you're going to spend more than $500 chasing one enterprise deal, pay the lawyer. The privacy policy is the cheapest line item in that funnel.

Cookie consent: the 30-minute fix everyone gets wrong

GDPR and DPDP require opt-in consent before non-essential cookies fire. CCPA requires opt-out (with a clear "Do Not Sell" mechanism). Your banner must let users grant granular consent across at least four buckets: strictly necessary, functional, analytics, and advertising.

The failure mode is firing Google Analytics, Hotjar, or PostHog on page load before the banner returns a decision. If you're using Vercel + Next.js, this means gating the analytics script behind a state hook tied to the consent decision, not just rendering it in <head>.

Cookiebot, Iubenda, and Termly all ship a consent banner that handles this for $0 to $50/month at early-stage scale. Pick one, install it once, and never write your own. A homegrown banner is a $1,000 mid-engineer week that fails an audit.

When to skip the generator and pay a lawyer

A generator is fine for the median pre-Series-A SaaS. Four situations push you off the template and into a paid draft.

B2B selling to enterprise. Once your contracts include SOC 2 attestations and custom Data Processing Addenda, your privacy policy needs to match the obligations in those DPAs. A template won't.

Healthcare and finance verticals. HIPAA, GLBA, PCI-DSS, and the EU AI Act for biometrics each layer sectoral rules on top of the general privacy regime. Generators don't cover them.

Children's data. COPPA in the US, GDPR-K in Europe, and the DPDP Act's children's consent provisions all require verifiable parental consent, age-gating, and a tighter retention story. The penalty for getting this wrong is large enough that the lawyer is the cheap option.

EU establishment without an EU office. Any non-EU company processing EU data at scale needs a GDPR Article 27 representative in the EU. A lawyer will set this up; a generator won't.

For everyone else, ship the generator output and budget a lawyer review within the first 12 months of revenue. The same build vs buy decision you'd run on any feature applies here: a privacy policy is a buy until enterprise sales force you to build.

DSARs: the request that breaks your weekend

A Data Subject Access Request is a user emailing you to say "tell me what you have on me, then delete it." GDPR gives you 30 days. CCPA gives you 45, with one 45-day extension. DPDP says "reasonable timeframe" and the Rules will pin it down.

You will get your first DSAR from a developer testing your compliance. Build the SOP before that happens.

A minimal runbook:

A privacy@yourdomain.com inbox monitored by a human.
A 24-hour acknowledgment template.
A Postgres script that selects every row keyed to a user ID across users, sessions, events, support_tickets, invoices, etc.
A second script that hard-deletes (or soft-deletes with a 30-day purge) the same rows.
A log of every DSAR with timestamp, user, action, and operator, kept for 24 months.

OneTrust and Osano sell DSAR-management tools that automate this; for a sub-Series-A team, a Notion runbook plus two SQL scripts is enough.

Privacy by design: the engineering work behind the policy

The policy is the document; privacy by design is the engineering. The policy is only as truthful as the codebase backing it.

Five engineering disciplines that turn a policy from fiction into fact:

Data minimization at signup. If you don't need the user's date of birth, don't collect it. Every field on the form is a future DSAR row and a future breach surface.
Encryption at rest and in transit. Postgres-level encryption, TLS 1.2+, secrets out of source control. Table stakes; auditors check.
Audit logging on admin reads. Every time an internal admin queries a user's data, log it. This is the receipt that protects you when an employee goes rogue.
Auto-delete for expired trials. A cron that wipes inactive trial accounts after 90 days reduces blast radius and matches the retention promise in your policy.
Documented prod database access. A short doc listing who has read access to the prod DB, refreshed quarterly. Useful for SOC 2, mandatory for enterprise sales.

This is unglamorous backend work. It's also the difference between a policy that holds up and a policy that gets you sued.

The 90-minute privacy policy roadmap

The whole exercise should take a single afternoon for an MVP. Block 90 minutes, do this in order, ship.

Inventory data and sub-processors (30 min). Open a Notion doc. List every form field you collect, every cookie you set, every third party in your package.json that talks to a user. This is the input to everything else.
Run a generator (20 min). Termly free tier or Iubenda. Answer the questionnaire honestly. Don't lie about whether you sell data; "no" is almost always the right answer for SaaS.
Replace boilerplate with named vendors (15 min). The generator will output "we use payment processors and analytics tools." Replace those two paragraphs with the named sub-processor table from earlier in this post.
Wire it up (15 min). Add /privacy to your router, link it from the footer, and add a checkbox on your signup form: "I agree to the Terms and Privacy Policy."
Calendar a 6-month review (10 min). Add a recurring calendar event titled "Privacy policy review." When it fires, scan your sub-processor list against your current package.json and your latest hires. If anything changed, update the policy.

That's the v1. It is honest, it is defensible for an early-stage product, and it can ship today.

Where engineering work fits

The policy itself is a writing job. The truthfulness of the policy is an engineering job: the audit log, the DSAR script, the auto-delete cron, the consent banner wired correctly into your analytics. That work is roughly a focused mid-engineer week, which on Cadence is the $1,000/week mid tier. If your product touches healthcare or finance, the senior tier at $1,500/week handles the harder edges (encryption-at-application-layer, key rotation, PII tokenization).

Every engineer on Cadence is AI-native by default, vetted on Cursor, Claude Code, and Copilot fluency before they unlock bookings. That matters for privacy plumbing because most of this work (writing a DSAR script, a consent gate, an audit logger) is exactly the kind of well-scoped backend task an AI-native engineer ships in a day with their tooling, not a week without it.

If you've validated the product, raised a round, and have an enterprise pilot in the pipeline, the hiring loop is the wrong shape for two weeks of privacy plumbing. Book a mid or senior engineer for one or two weeks, ship the policy and the engineering behind it, and move on. If it's working, keep them. If it isn't, end the week.

Need the engineering work behind the policy (DSAR script, consent banner, audit log, auto-delete cron) shipped this month? Book a mid Cadence engineer at $1,000/week and start with a 48-hour free trial. No notice period, replace any week, daily ratings.

FAQ

Do I need a privacy policy if I haven't launched yet?

Yes. The moment you collect a single email on a waitlist, GDPR Article 13 applies. Ship a one-page policy before the first signup form goes live, even if the rest of the site is a pre-launch landing page.

Is a free Termly policy enough for a B2B SaaS?

For a self-serve product under $25M ARR with no healthcare or finance exposure, usually yes. For enterprise contracts requiring SOC 2 attestations and custom Data Processing Addenda, pay a privacy lawyer $1,500 to $3,500 to draft the real thing. The deal is paying for it.

How is a privacy policy different from terms of service?

The privacy policy is a legal notice about data: what you collect, why, who you share it with, and the user's rights. The Terms of Service is the contract about acceptable use, payment, and liability. You need both, and they should link to each other from your footer.

What is a sub-processor list and where do I put it?

It's the named list of every third party that touches user data: Stripe, AWS, Resend, Supabase, PostHog, etc. Publish it in section 4 or 5 of the policy, or at a dedicated /privacy/subprocessors URL linked from the policy. Update it within 30 days whenever you swap a vendor.

When does the India DPDP Act actually start mattering?

The Rules were notified on November 13, 2025. Full implementation lands May 13, 2027. If you have any Indian users today, treat the disclosure obligations as live and plan for a Data Protection Officer appointment during 2026 or 2027. Most generators (Termly, Iubenda, CookieYes) already ship a DPDP module.

All posts