Methodology & sources

How ComplyKit works

ComplyKit turns a short questionnaire into three documents — a privacy policy, terms of service, and a cookie notice — plus a working cookie-consent banner. It does the whole job inside your browser. This page explains how the documents are assembled, where the templates come from, and the limits you need to understand before you publish anything.

The privacy guarantee: nothing leaves your browser

This is a tool about privacy, so it would be absurd to harvest yours. ComplyKit has no backend. Everything you type into the questionnaire is used to assemble the documents in JavaScript, locally, in the same tab you’re looking at.

  • No network requests with your answers. Your company name, email, and choices are never uploaded, POSTed, beaconed, or sent anywhere.
  • No logging or storage. Nothing you enter is written to a database, a log, or analytics. Close or reload the tab and it’s gone — so download or copy anything you want to keep.
  • It works offline. Load the page once, disconnect from the internet, and the generator still runs. That’s the simplest proof there’s nothing to upload to.
Verify it yourself. Open your browser’s developer tools, switch to the Network tab, and fill in the form. You won’t see a request carrying your input — because there isn’t one. The only network activity is loading the page, its stylesheet, the script, and the web fonts.

How generation works

ComplyKit is a deterministic template engine, not an AI writer. Your answers map to a structured model; the model decides which clauses are included; and each document is rendered from that model into the live preview and the downloadable files.

  1. You answer. Name, contact, what you collect, the third parties you use, the regions you serve, and a minimum-age policy.
  2. The model assembles. Each toggle and checkbox flips clauses on or off. Some answers imply others — choosing Stripe, for instance, automatically enables the payment-processing clauses; choosing Google Analytics enables analytics and cookies.
  3. The documents render. The same model produces the on-screen preview and every export, so what you download is exactly what you reviewed. Each document is stamped with the day you generated it and a version number derived from that date.

Because the output is rendered with safe DOM construction and HTML-escaping, anything you type — even angle brackets or quotes in your company name — is treated as plain text, never as markup. The tool cannot be turned against you with a crafted input.

Conditional clauses

The point of ComplyKit is that you only get the clauses that apply to you. A few of the rules:

  • Stripe selected → a payment-processing section explaining that card data is handled by Stripe and not stored on your servers.
  • Analytics selected → a tracking section plus a real, itemized opt-out path (cookie banner, browser settings, Google’s opt-out add-on, Do-Not-Track / Global Privacy Control).
  • User accounts selected → an account-data section covering what’s stored, how to edit it, and how to delete the account.
  • EU/UK selected → GDPR legal-bases and data-subject-rights sections, plus an international-transfers clause.
  • California selected → CCPA/CPRA consumer-rights section with a “Do Not Sell or Share” statement.
  • Minimum age → the children’s-privacy and eligibility wording is written to match the age you choose.

The banner snippet is self-contained vanilla JavaScript with no dependencies and no network calls. It’s built to be correct by default:

  • Categorized. Necessary cookies are always on and require no consent; analytics and marketing are separate, opt-in categories that only appear if you selected them.
  • Consent-first. Non-essential categories are off until the visitor accepts. The banner stores the choice in localStorage and exposes it as window.cookieConsent.
  • Event-driven. It dispatches a cookieconsent event so you can load analytics or marketing tags only after the matching consent is granted — which is the part most homemade banners get wrong.
  • Accessible. It’s a labelled dialog, fully keyboard-operable, with visible focus states and a window.openCookieSettings() hook so visitors can change their mind.
Important: a banner that records consent but still loads tracking scripts regardless is not compliant. You must wire your own analytics/marketing tags to wait for the consent flags the banner sets.

Methodology & sources

ComplyKit’s templates are written to track the structure and requirements of the official legal texts and the public guidance issued about them, not copied from any commercial generator. The clause set derives from:

  • EU General Data Protection Regulation (GDPR), Regulation (EU) 2016/679. The lawful-bases (Art. 6) and data-subject-rights (Arts. 12–22) sections follow the rights and obligations set out in the regulation’s official consolidated text on EUR-Lex (eur-lex.europa.eu).
  • UK GDPR & the ICO’s guidance. The UK rights wording mirrors the Information Commissioner’s Office guide to the UK GDPR (ico.org.uk).
  • California Consumer Privacy Act (CCPA), as amended by the CPRA. The consumer-rights and “Do Not Sell or Share” sections track the statute and the California Privacy Protection Agency / Attorney General materials (oag.ca.gov/privacy/ccpa).
  • ePrivacy Directive (the “cookie law”), Directive 2002/58/EC. The consent-before-non-essential-cookies model in the banner follows the directive and EDPB cookie-consent guidance.
  • COPPA. The children’s-data floor of 13 reflects the US Children’s Online Privacy Protection Act; the 16 default reflects the GDPR’s digital-consent age.

Citing a source means the template was modeled on it for structure and required elements. It does not mean any regulator has reviewed or endorsed the output. Legal texts change; always check the current version.

This is a template — not legal advice

Important: ComplyKit is a drafting tool, not a law firm, and its output is not legal advice. A clean-looking document does not mean you are compliant.

A real privacy program depends on what your code and your company actually do — the data you truly collect, where it flows, who can see it, how long you keep it, and the specific laws of every place you operate. A generated document can describe those things, but it can’t verify them. The most common compliance failure is a polished policy that doesn’t match reality; that is worse than having none, because it’s a written misrepresentation.

Use ComplyKit to get to a strong first draft fast, then:

  • Make it true. Edit every clause so it matches what your app really does.
  • Have a lawyer review it. Especially before you take payments, handle health/financial/children’s data, or operate across borders.
  • Keep it current. Re-generate when what you collect changes, and keep the “last updated” date honest.

If you want that review, talk to Copper Bay Labs.

Build my documents