GDPR Privacy Policy Template: The Nine Inputs to Gather First

A GDPR privacy policy template is the last twenty minutes of the job, not the first. Every template you can download asks the same thing of you: a list of what personal data you hold, where it came from, where it goes next, and how long it stays. For a web design studio running client intake, that list is short and unusually specific — and it is the part no template can fill in. This page assembles the inputs first, then points at where the templates live.

Short answer: Before a template is useful, you need nine facts written down: the categories of data you collect, whose data it is, how it reached you, why you hold it, where it is stored, which third parties touch it, how long you keep it, how someone reaches you, and who handles an access or deletion request. The ICO publishes a notice builder that walks through those sections, and gdpr.eu's guide covers the same ground in prose.

The inventory a template assumes you already have

Fill the left column for your own studio before you open any template. The right column shows the kind of answer that is specific enough to be usable — a studio's answers will differ.

Nine rows. Most studios can complete seven of them in a sitting; the two that stall are third parties and retention, and both stall for the same reason — nobody has looked at the list of tools since the studio started.

Three intake-specific facts most templates skip

Generic templates are written for a website with a contact form. A client portal collects something different, and three details fall outside the standard sections.

Uploads are not form fields

A brief with a file upload is a different category from a brief without one. A client uploading brand assets can also hand you a logo pack containing photographs of identifiable people, a customer list inside a spreadsheet, or an old newsletter export. None of that was requested; all of it arrives.

This is worth naming as its own row in the inventory, because the answer to "what do you collect" changes from a fixed list of fields to a fixed list of fields plus whatever a client uploads. A practical response is a stated upload scope in the intake step itself — what belongs in the folder, and what should be sent another way.

The client's customers are a second layer

When a webshop client uploads a product feed with reviewer names, the studio is holding data about people who have never heard of the studio. Whether that changes anything for your notice is a question for the client's own arrangements and, where needed, for counsel — but the inventory row exists either way, and it is the row that connects a privacy notice to a data processing agreement. The related data processing agreement template covers that document separately.

Portals without accounts still leave traces

Letting a client complete a brief without creating an account removes a password, not a record. Session identifiers, upload timestamps and delivery logs still exist. If your intake works this way, the notice should describe what a link-based session records — a template built for a login-based SaaS will not have that paragraph.

Retention: the row a template leaves blank

Every generic template contains the sentence "we keep data no longer than necessary" and no number. The number is the part a reader — and a client's own auditor — actually needs, and for a client portal it differs per row.

The periods below are a starting point to replace with your own; what matters is that each one has a reason attached rather than a round figure.

Two things this table makes visible that a sentence does not. First, the shortest period in the list is the one that matters most: uploads of a project that never started. That is where studios silently accumulate other people's customer lists for years. Second, the last row is deliberately not a number — commercial retention is not a design decision, and a template that fills it in for you is guessing about your jurisdiction.

Set a calendar reminder at half the shortest period — 15 days here — to check that deletion is actually happening. A retention promise nobody verifies is the same as no promise, except that it is now written down.

From inventory to template in five steps

1. List the tools that touch an intake. Open your last completed project and follow the file: which service received the upload, which one stored it, which one emailed the client, which one issued the invoice. 2. Write one sentence per tool naming what it processes. If you cannot write the sentence, that is the gap, not a wording problem. 3. Set a retention rule you can actually run. "Deleted on request" is not a rule; "archived at project close, removed after a defined period" is one you can put in a calendar. 4. Pick a template and map your rows onto its sections. The ICO builder and the gdpr.eu guide both structure the same content; either gives you the section order. 5. Have it reviewed by someone qualified in your jurisdiction before you publish it. A worksheet is preparation, not a substitute for that step.

A short check before publishing

• Every tool in step 1 appears somewhere in the notice.
• Every claim in the notice matches something you actually do today, not something you plan to do.
• The contact route reaches an inbox a person reads within a working week.
• The upload scope described in the notice matches the scope described in the intake form itself.
• The retention rule has an owner and a trigger, not just a duration.
• Someone qualified has reviewed it for your jurisdiction.

Where the intake form itself is concerned, the field list and the notice should be built together rather than in sequence — the web design template for client intake walks through that field list.

Frequently asked questions

Is a downloadable template enough on its own?

A template supplies structure and section order. The content is specific to what your studio holds and which services it uses, and those parts have to be written by someone who knows both. Treat a template as a form to complete rather than a document to publish.

How do I find every third party that touches client data?

Follow one real project end to end instead of trying to recall the list. Billing history and connected-app screens in your main tools surface services that get forgotten, particularly analytics, form backends and file-conversion utilities added for a single job.

Do I need something different for clients outside the EU?

The question is worth putting to someone qualified rather than answered from a template, because it depends on where you and your client are established and where the data is stored. The inventory above is what that conversation needs as input.

What changes when I add a new tool?

The inventory gains a row, and the notice needs the matching sentence. Keeping the inventory as a separate working file rather than only inside the published notice makes that a two-minute edit instead of a rewrite.