How to Write a Privacy Policy for a Static Site

June 19, 2026 · 13 min read · How-to

A static site still collects data—analytics hits, form submissions, server logs, and advertising cookies if you monetize. Privacy laws including the EU GDPR and UK GDPR, California CPRA, and ePrivacy rules require transparent notices even when you never touch a database. This how-to explains how to write a practical privacy policy page for LaunchStatic-style sites, citing official regulator guidance at a high level. It is educational, not legal advice; have counsel review before handling sensitive data or EU children’s audiences.

Identify what data you actually process

Audit every touchpoint. Typical static marketing sites process: (1) voluntary data—emails via Formspree; (2) analytics data—page URLs, referrers, device type via Umami or Plausible; (3) hosting logs—IP addresses, user agents retained by Cloudflare or GitHub for security; (4) cookies—consent banners, AdSense if enabled. List processors, not just tools—Formspree Inc., Cloudflare Inc., Google if you add Ads. If you only serve static HTML with no analytics, say so honestly, but remember TLS terminators still see IPs briefly.

Structure the policy page for humans

Regulators expect clear language. Use headings scanners can navigate. A solid outline:

1. Who we are (controller name, contact email)
2. What data we collect and why (purposes)
3. Legal bases (contract, consent, legitimate interests)
4. Third parties and international transfers
5. Retention periods
6. Your rights (access, deletion, objection)
7. Children's privacy
8. Changes to this policy
9. How to contact us / supervisory authority

Link the policy from the site footer on every page, including 404.html. Match the URL you declare in AdSense and Formspree dashboards.

Disclose third-party form processors

When using Formspree, state that submissions are transmitted to Formspree for email delivery, which fields you collect, and retention per Formspree's documentation. Example plain-language sentence: "When you submit the waitlist form, we collect your email address to send launch updates; our processor Formspree stores submissions on our behalf." Link to Formspree's privacy policy. If you export CSVs locally, mention that copies may reside in your inbox or spreadsheet tools.

<section id="processors">
  <h2>Third-party services</h2>
  <p>We use Formspree (formspree.io) to process contact and waitlist
  submissions. Their privacy policy explains how they handle data
  on our behalf.</p>
</section>

Cover analytics transparently

If you run Umami Cloud, describe collected metrics (pages viewed, referrer, browser type), whether cookies are used, and opt-out options if your plan provides them. The European Data Protection Board emphasizes purpose limitation—do not claim "essential" processing for marketing analytics. Legitimate interest may apply to aggregated, low-invasion analytics in some contexts, but consent banners are safer when in doubt, especially alongside ads.

Explain cookies and consent

Separate essential cookies (security, load balancing) from analytics and advertising. Link a dedicated cookie policy or section listing each cookie name, provider, purpose, and duration. If you use Google AdSense later, implement Consent Mode v2 per Google's EU requirements and document it. LaunchStatic's default cookie banner points to /cookies.html—keep that page synchronized with actual practices.

Retention and security

State realistic retention: "Waitlist emails until launch plus 12 months" beats vague "as long as necessary." Mention HTTPS enforced by your host, access controls on admin accounts (GitHub, Cloudflare), and that no system is 100% secure. If you do not sell personal data, say so explicitly—CPRA and many state laws require clarity on "sale" and "sharing."

User rights and requests

Provide a contact email for privacy requests—privacy@example.com or your general hello inbox. Describe how users can access, correct, or delete data you control. If Formspree holds submissions, explain you will forward deletion requests to them or use their dashboard tools. EU residents may lodge complaints with their local supervisory authority; name one example (e.g., ICO in the UK) without implying you are EU-established unless true.

Keep the policy updated

Bump the "Last updated" date when you add AdSense, switch analytics vendors, or collect new fields. Version major changes in git. Avoid copying another startup's policy wholesale—practices differ, and outdated templates create liability. The FTC has brought actions against companies whose policies misstated actual data use.

• Footer links to /privacy.html on all pages
• Every third-party processor named
• Purposes match real site behavior
• Contact email monitored by a human
• Cookie policy aligned with banner text
• Last updated date visible at top

Publish as static HTML

Create privacy.html with the same header/footer as other pages for trust and crawlability. Use plain sentences, short paragraphs, and avoid legalese where possible—ICO and CNIL both encourage understandable notices. Add Article or WebPage JSON-LD only if it helps; accuracy matters more than markup. Cross-link from your contact page and signup forms ("See our Privacy Policy").

International transfers and subprocessors

US-based hosts like Cloudflare and Formspree may process EU visitors' data in the United States. GDPR Chapter V requires appropriate safeguards—often Standard Contractual Clauses in vendor DPAs. Link to processor DPAs where available and state that you rely on contractual protections. If you self-host in the EU, say so; do not claim EU-only hosting if your CDN edges are global.

Children and sensitive categories

If your product is not directed at children under 13 (or 16 in some EU states), say you do not knowingly collect children's data and instruct parents to contact you for deletion. Health, financial, or biometric data triggers stricter rules—static marketing sites rarely collect these, but do not add optional form fields you are not prepared to govern. COPPA and GDPR children's provisions are not satisfied by a generic boilerplate paragraph alone if your product is a kids' app.

Template starting point

Review LaunchStatic's own privacy.html as a structural reference—not a copy-paste legal document. Replace entity name, contact emails, processor list, and retention periods. Add sections you lack (advertising, affiliate links) and delete sections that do not apply. Store the policy in git so "Last updated" dates reflect real diffs auditors can trace.

Related: LaunchStatic privacy example Legal pages checklist Add Formspree Set up Umami Cookie policy page