# Design and Practice of the Privacy Policy
How to structure a privacy policy: structural patterns, the layered model, the level of detail for each item, delivery channels, typical mistakes, updating and a checklist.
> Quelle: https://www.thomashelbing.com/en/wissen/dsgvo-hub/einzelthemen/transparenzpflichten/1.3.5.4-gestaltung-und-praxis
> Sprache: en
The mandatory information under [Article 13](/docs/dsgvo-hub/einzelthemen/transparenzpflichten/1.3.5.2-inhalt-bei-direkterhebung) and [Article 14 GDPR](/docs/dsgvo-hub/einzelthemen/transparenzpflichten/1.3.5.3-inhalt-bei-dritterhebung) is the compulsory minimum; the way it is presented determines whether the information fulfills its purpose. This page shows how completeness and intelligibility can be reconciled.
**Key takeaways**
* There are three patterns for structuring the document: by **mandatory information items**, by **topic** or by **legal basis**.
* A **layered model** puts the most important information up front and links to the details, which avoids information overload.
* **Categories of data, purposes and legal basis** must remain matched to one another; this is the most common weak point.
* Where changes are **material**, the data subject must be informed actively; a reference to "please check regularly" is not sufficient.
* The **level of detail** is governed by intelligibility and maintainability: neither too generic nor obsessed with detail.
## 1. Structure [#1-structure]
### 1.1 Three structural patterns [#11-three-structural-patterns]
| Pattern | Structure | Suitable for |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- |
| By mandatory information items | The catalog of Articles 13 and 14 GDPR serves as the outline (controller, purposes, recipients, storage period and so forth). | Simpler processing operations with a manageable set of purposes. |
| By topic | Generic information up front, then separate sections for each topic or category of data, supplemented by catch-all provisions. | Subject areas that can be cleanly separated, for example on websites (contact form, newsletter, user account, analytics). |
| By legal basis | An outline organized by legal bases, with the data, purposes and storage periods set out under each of them. | Complex, multi-layered processing operations, for example general employee or customer notices. |
The structure by legal basis shapes above all the general notices for customers, business partners and employees. There the outline follows the grounds for lawful processing: performance of contractual obligations (Article 6(1)(b) GDPR), a balancing of interests (Article 6(1)(f) GDPR), consent (Article 6(1)(a) GDPR) and compliance with legal obligations (Article 6(1)(c) GDPR). Under each legal basis, the associated purposes, categories of data and storage periods are brought together. For ongoing business or employment relationships with many interlocking processing operations, this structure is clearer than the topic-based one because it places the legal assessment in the foreground.
### 1.2 Catch-all provisions [#12-catch-all-provisions]
With the topic-based structure, a fallback rule at the end is advisable: "Unless stated otherwise above, the following applies ...". This keeps the document complete even where a processing operation is not listed separately. Without a catch-all provision, gaps arise as soon as a new purpose is added.
### 1.3 A proven architectural pattern [#13-a-proven-architectural-pattern]
For extensive online services, a tiered pattern that combines the three structural patterns with the catch-all provision has proven itself. It divides the notice into five parts:
1. **Generic information up front:** the controller, where applicable the data protection officer and the representative, plus a brief statement of the services and the audience the notice applies to.
2. **Topic blocks by function:** a separate section for each function that the user perceives as such, for example server operation, embedded third-party content, contact form, newsletter and user account. Each block briefly states the data processed, the purpose, the legal basis and any particularities.
3. **Supplementary general part:** cross-cutting information that applies to several blocks, for example a list of the purposes of use with the corresponding categories of data and legal bases, the storage period, the categories of recipients and transfers to third countries. This is also where the catch-all provision takes effect: whatever is not specifically addressed above is governed by this part.
4. **Glossary:** a single definition of the recurring terms (categories of data, purposes, legal bases, key roles) that the blocks refer to.
5. **Rights of the data subject:** data subject rights, the right to object and the right to lodge a complaint, bundled at the end.
The value of this pattern lies in the interplay: the topic blocks remain short because categories of data and purposes are explained only once in the glossary; the general part together with the catch-all provision prevents gaps when a new service is added; and the rights appear in a fixed, easily located place. The pattern can be transferred to apps and other online services.
> **Sample wording (topic block on server operation):** When you access our website, our server automatically records access data, such as your IP address, the date and time of access, the page requested and details of your browser and operating system. We use this data to deliver the content you have requested and for security purposes and protection against improper use. We store the access data for the duration of the retention period for access data (\[7 days]). The legal basis is our legitimate interest in the secure and trouble-free operation of our website (Article 6(1)(f) GDPR).
## 2. Layered model [#2-layered-model]
Given the volume of mandatory information, a multi-tier structure (layered approach) is advisable: the most important information comes first, the remainder follows separately, for example via a link or an expandable text. "Important" as a rule means: the controller, the data, the purpose, the rights and how to make contact.
The first layer is the principal means of first contact; it should contain the core information and the consequences of the processing that matter most to the individual. In addition, contextual notices immediately at the point of collection help (for example a short explanation next to the field for the telephone number) and, for ongoing services, a privacy dashboard through which the individual can review their settings ([Article 29 Working Party, WP 260 rev.01, Guidelines on transparency, adopted on 11 April 2018](https://www.edpb.europa.eu/our-work-tools/our-documents/article-29-working-party-guidelines-transparency-under-regulation_en), paras. 35 et seq.). One point is important: the layers must not contradict one another, and the first layer must not conceal any mandatory information.
## 3. Level of detail for each item [#3-level-of-detail-for-each-item]
* **Purposes:** state them specifically, do not lapse into empty phrases (examples under [General requirements](/docs/dsgvo-hub/einzelthemen/transparenzpflichten/1.3.5.1-allgemeine-anforderungen)).
* **Storage period:** criteria are sufficient; general criteria plus specific periods where these are settled are recommended. "As long as necessary" is not enough.
* **Recipients:** categories of recipients are sufficient, but they should be meaningful. Internally these are departments, externally they also include processors and joint controllers. Name them specifically where this makes sense, otherwise state the sector (for example transport service providers) or the location (for example hosting providers in Germany). What counts when setting the level of detail is how easily the information can be kept up to date, its relevance and any interests in confidentiality.
* **Third country:** name the specific country, state whether an adequacy decision exists, and point to the safeguard mechanism (for example standard contractual clauses and where they can be obtained).
Beyond the individual items, it is worth explaining recurring terms once and then using them consistently. This applies above all to categories of data (for example access data as the server data generated automatically with every page view, or device data as information on device type, operating system and browser), to central purposes (for example provision of functionality or protection against misuse) and to roles (for example processor). Definitions of this kind shorten the individual sections and at the same time improve intelligibility and maintainability, because a change only has to be made in one place.
## 4. Delivery channels [#4-delivery-channels]
How the information reaches the individual depends on the context of collection. Established channels:
* by email;
* the footer of websites; the reverse side or footer of forms;
* links or QR codes on objects and packaging;
* an oral notice referring to the notice available for consultation;
* signs and stands for video surveillance or at events;
* email signatures, invoices, business letters.
## 5. Tips and typical mistakes [#5-tips-and-typical-mistakes]
### 5.1 Tips [#51-tips]
**Begin with an introduction:**
clarify what the notice applies to and which audience it addresses.
**Explain the categories of data**
and structure the presentation conceptually along those lines.
Provide for
**catch-all provisions**
so that no processing operation is left unaddressed.
**Explain terms**
where necessary (for example "IP address") and look to comparable services for orientation.
Deal with
**cookies and consent**
separately from the privacy notice.
Use the term
**privacy notice**
rather than "privacy policy", because what is involved is information and not a declaration by the individual.
### 5.2 Typical mistakes [#52-typical-mistakes]
* The **mapping** between category of data, purpose and legal basis is lost; the processing becomes non-transparent.
* **Drifting into extremes:** too generic (saying nothing) or obsessed with detail (unintelligible, barely maintainable).
* **No overview** or short summary; the individual cannot find the important information.
* **No contextual notices** where the data is actually collected.
## 6. Updating [#6-updating]
The transparency obligation applies throughout the entire processing lifecycle, not only at the point of collection. Where a privacy policy changes **materially**, for example in the event of a change of purpose, a change of controller or a new way of exercising rights, the change must be communicated actively to the data subject (by email, letter or a prominent notice), separately and not mixed in with advertising. A mere reference asking the individual to "check the notice regularly for changes" is not sufficient and runs counter to the principle of fairness (WP 260 rev.01, paras. 29 et seq.). Purely editorial corrections need not be communicated.
Behind the obligation to update stands the idea that transparency accompanies the entire processing lifecycle, not merely the moment of collection. Beyond the cases already mentioned, in practice a new recipient or service provider and a first transfer to a third country count above all as material changes, because they noticeably affect the position of the data subject. The benchmark always remains whether anything changes for the individual in the substance or the scope of the processing.
## 7. Checklist [#7-checklist]
Before publication, the privacy policy can be reviewed against the mandatory information items. For each item, one of the following applies: it has been provided, it is already known to the individual, it is exceptionally dispensable or it is covered by an exemption (see the overview in the [chapter overview](/docs/dsgvo-hub/einzelthemen/transparenzpflichten)).
* [ ] Name and contact details of the controller and, where applicable, of the representative
* [ ] Contact details of the data protection officer (if one has been designated)
* [ ] Purposes and legal basis, matched to one another
* [ ] Legitimate interests stated (where Article 6(1)(f) GDPR applies)
* [ ] Recipients or meaningful categories of recipients
* [ ] Transfer to a third country and safeguards (where applicable)
* [ ] Storage period or criteria (no empty phrase)
* [ ] Data subject rights and right to lodge a complaint, with the right to object highlighted
* [ ] Information on withdrawal of consent (where applicable)
* [ ] Obligation to provide the data and the consequences (direct collection only)
* [ ] Information on automated decision-making and the logic involved (where applicable)
* [ ] Categories of data and the source (collection from third parties only)
* [ ] Introduction, catch-all provision and contextual notices present
* [ ] Information actively provided, easily accessible, free of charge
## 8. Frequently asked questions [#8-frequently-asked-questions]
Substantively the same. The more apt term is "privacy notice", because what is involved is information and not a declaration or agreement by the data subject. The more common term "privacy policy" does no harm, however.
On a website, a clearly recognizable link under a familiar label on every page is the rule. What is decisive is that the individual can actually take note of the notice before the data is collected. Where data is collected through a form, a notice belongs at the point of collection.
No. The privacy policy does not call for agreement. A checkbox suggests consent, which is neither necessary nor intended here. Consent is obtained only where the processing is actually based on it.
Only in the case of material changes (purpose, controller, the way rights are exercised). Purely editorial corrections need not be communicated. A reference asking the individual to check regularly on their own is not sufficient.
## 9. Primary sources [#9-primary-sources]
---
## Über den Autor
Dieser Beitrag wurde von [Dr. Thomas Helbing, Fachanwalt für IT-Recht in München](https://www.thomashelbing.com/en) verfasst.
Dr. Helbing wird seit 2020 durchgehend bis heute (2026) vom Handelsblatt als einer der **„Deutschlands besten Anwälte"** im Bereich IT-Recht und Datenschutzrecht [ausgezeichnet](https://www.thomashelbing.com/en#auszeichnungen).
Laut Kanzleimonitor.de (Ausgaben 2024–2026) zählt er zu den **führenden Anwälten für Datenschutz und IT-Recht** und ist unter den **Top-100 Anwälten in Deutschland (2024/25)** gelistet. Kanzleimonitor gilt als besonders aussagekräftige Marktstudie, da sie ausschließlich auf persönlichen Empfehlungen von Unternehmensjuristen basiert.
Dr. Helbing verfügt über **langjährige Beratungserfahrung im Datenschutz- und IT-Recht** und berät Mandanten unterschiedlichster Größen, vom Startup über wachstumsstarke SaaS-Unternehmen und Unicorns bis hin zu internationalen Konzernen.
Sein [beruflicher Hintergrund](https://www.thomashelbing.com/en#stationen) umfasst das **gesamte Spektrum der Praxis im IT- und Technologierecht**. Er begann seine Laufbahn in einer internationalen Großkanzlei, sammelte anschließend **Inhouse-Erfahrung in einem DAX-Unternehmen** und ist selbst **Unternehmer und Gründer mehrerer digitaler Projekte**. Darüber hinaus verfügt er über **praktische Programmiererfahrung**, wodurch er technische Systeme, Softwarearchitekturen und digitale Geschäftsmodelle nicht nur juristisch, sondern auch aus technischer Perspektive versteht.
Zu seinen [Mandanten](https://www.thomashelbing.com/en#referenzen) zählen seit vielen Jahren unter anderem **Technologieunternehmen und SaaS-Anbieter**, führende **deutsche Forschungseinrichtungen** sowie eine **systemrelevante deutsche Großbank**. Seine Beratungsschwerpunkte liegen insbesondere in den Bereichen **DSGVO-Compliance, Datenökonomie, SaaS, KI-Regulierung und IT-Vertragsrecht**.