¶ Privacy by Design und by Default
Beispieldokument: Diese Seite ist ein nicht freigegebener Musterprozess für die fiktive „Muster GmbH“. Sie belegt weder eine reale Umsetzung noch die Rechtmäßigkeit, Sicherheit oder Freigabe eines Produkts oder Verfahrens.
Frühzeitigkeit: Datenschutzanforderungen werden bei der Festlegung der Verarbeitungsmittel und während der gesamten Verarbeitung berücksichtigt – nicht erst kurz vor der Inbetriebnahme.
Voreinstellungsregel: Ohne aktives Eingreifen einer Person dürfen standardmäßig nur die für den jeweiligen Zweck erforderlichen personenbezogenen Daten verarbeitet, gespeichert und zugänglich gemacht werden.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | DSGVO-MA-05-04 |
| Dokumentenart | Musterverfahren für Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen |
| Wiki.js-Pfad | /DSGVO/05-Risiken-DSFA-und-TOM/Privacy-by-Design-und-by-Default |
| Verantwortlich | festzulegender Prozesseigner / Projekt- oder Produktverantwortlicher |
| Fachlich geprüft durch | Datenschutzbeauftragte/r, sofern benannt, Datenschutzkoordination, Informationssicherheit, IT, Recht und betroffene Fachrollen |
| Freigabe durch | Geschäftsführung beziehungsweise dokumentierte befugte Leitung |
| Status | Entwurf – Projekt-Gates, Prüfkriterien, Rollen und Freigaben nicht organisationsbezogen umgesetzt |
| Version | 0.1 |
| Stand | 08.08.2026 |
| Gültig ab | Nach Anpassung, Praxistest, fachlicher Prüfung und formaler Freigabe |
| Nächste Prüfung | Mindestens jährlich sowie bei Rechts-, Risiko-, Technik-, Produkt- oder Prozessänderungen |
| Schutzklasse | Intern; Architekturen, Schwachstellen, Testdaten und Abnahmen geschützt |
| DSGVO-Bezug | Erwägungsgründe 26, 28, 75, 76 und 78 sowie Artikel 5, 24, 25, 32 und 35 DSGVO |
| Schnittstellen | VVT, Projekte, Beschaffung, Entwicklung, Änderungen, DSFA, TOM, Testdaten, Löschung und Lieferanten |
Datenschutzanforderungen werden vor der Umsetzung bestimmt, in Architektur und Voreinstellungen eingebaut, geprüft und über den Lebenszyklus erhalten. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Zweck
Das Verfahren integriert Datenschutzanforderungen in Ideen, Projekte, Beschaffung, Entwicklung, Konfiguration, Betrieb, Änderung und Außerbetriebnahme. Es schafft kontrollierte Entscheidungspunkte, bevor personenbezogene Daten verarbeitet werden.
Artikel 25 verlangt angemessene technische und organisatorische Maßnahmen unter Berücksichtigung von Stand der Technik, Implementierungskosten, Art, Umfang, Umständen und Zwecken sowie der Risiken für Rechte und Freiheiten. Diese Faktoren werden konkret dokumentiert; ein pauschaler Hinweis auf Kosten oder ein Produktzertifikat genügt nicht.
¶ 2. Zwei miteinander verbundene Pflichten
| Prinzip | Steuerungsfrage |
|---|---|
| Datenschutz durch Technikgestaltung | Wie werden Datenschutzgrundsätze, Rechte und Rechenschaft bereits in Anforderungen, Architektur und Prozess eingebaut? |
| Datenschutz durch datenschutzfreundliche Voreinstellungen | Welche Einstellungen gelten ohne aktives Eingreifen und begrenzen Datenmenge, Umfang der Verarbeitung, Speicherdauer und Zugänglichkeit auf das Erforderliche? |
Die Voreinstellung wird pro Zweck bewertet. Komfort, Marktüblichkeit oder technisch mögliche Datenerhebung begründen keine Erforderlichkeit.
¶ 3. Auslöser
Das Verfahren wird mindestens ausgelöst bei:
- neuen oder wesentlich geänderten Verarbeitungstätigkeiten,
- Produkten, Apps, Portalen, Formularen, Kameras, Sensoren oder Analyseverfahren,
- Softwareentwicklung, Cloud-Einführung, Beschaffung und Lieferantenwechsel,
- neuen Datenquellen, Verknüpfungen, Empfängern oder Drittlandzugriffen,
- Profiling, automatisierten Entscheidungen, KI- oder Monitoring-Funktionen,
- Änderungen von Zweck, Rechtsgrundlage, Aufbewahrung, Berechtigungen oder Voreinstellungen,
- Migration, Schnittstellenänderung, Testbetrieb oder Außerbetriebnahme.
Kleine Änderungen dürfen nur nach dokumentiertem Screening als datenschutzneutral eingestuft werden.
¶ 4. Eingangsinformationen
- Projekt-, Produkt- oder Änderungs-ID,
- betroffene VVT-Einträge, Zwecke und Rechtsgrundlagen,
- Daten- und Personengruppen einschließlich Schutzbedürftigkeit,
- Datenfluss, Systeme, Schnittstellen, Empfänger und Dienstleister,
- Funktions-, Geschäfts- und Nutzungsanforderungen,
- Speicher-, Lösch-, Test-, Support- und Drittlandkontext,
- Risiko- und DSFA-Screening,
- vorhandene TOM und nachgewiesener Geltungsbereich,
- Annahmen, offene Fragen und geplante Entscheidungstermine.
¶ 5. Projekt-Gates
| Gate | Mindestentscheidung | Austrittskriterium |
|---|---|---|
| 1 – Anlass und Scope | Zwecke, Daten, Personen, Rollen und Grenzen erfasst | Verantwortlichkeit und VVT-/Projektbezug eindeutig |
| 2 – Anforderungen | Rechtsgrundlage, Grundsätze, Rechte, Fristen, Risiken und DSFA-Screening bestimmt | prüfbare Datenschutzanforderungen freigegeben |
| 3 – Gestaltung | Architektur, Datenfluss, Voreinstellungen, TOM und Lieferantenanforderungen bewertet | begründetes Soll-Design ohne ungeklärte kritische Lücke |
| 4 – Test und Freigabe | Soll-Ist-Abgleich, Funktions-, Sicherheits- und Datenschutztests durchgeführt | Abweichungen entschieden, Freigabe befugt dokumentiert |
| 5 – Betrieb und Änderung | Monitoring, Rechte, Löschung, Vorfälle und Reviews funktionieren | Wirksamkeit belegt und Änderungen erneut bewertet |
Ein nicht erfülltes Gate führt zu Nacharbeit, begründeter Zurückstellung oder Abbruch. Zeitdruck ist keine stillschweigende Ausnahme.
¶ 6. Gestaltungsanforderungen ableiten
Für jede Verarbeitung werden mindestens geprüft:
- Rechtmäßigkeit, Zweckbindung und verständliche Transparenz,
- Datenminimierung bei Feldern, Quellen, Genauigkeit, Häufigkeit, Dauer und Kopien,
- Trennung von Zwecken, Mandanten, Rollen und Zuordnungswissen,
- Richtigkeit, Berichtigung und nachvollziehbare Datenherkunft,
- Aufbewahrungsereignisse, Sperren, Löschung und Backupbehandlung,
- Zugriff, Authentifizierung, Protokollierung, Verschlüsselung und Wiederherstellung,
- Auskunft, Export, Einschränkung, Widerspruch und menschliche Intervention,
- Verhinderung unbeabsichtigter Veröffentlichung oder übermäßiger Suchbarkeit,
- Lieferantensteuerung, Unterauftragnehmer, Support und Exit,
- kontrollierte Testdaten und sichere Entwicklungsumgebungen.
Jede Anforderung erhält Owner, Priorität, Akzeptanzkriterium, Umsetzungs- und Nachweisreferenz.
¶ 7. Datenschutzfreundliche Voreinstellungen
Ohne aktive Auswahl gelten insbesondere:
- nur erforderliche Datenfelder und Funktionen,
- kleinster erforderlicher Empfängerkreis und Berechtigungsumfang,
- kürzeste begründete Speicher- und Protokollierungsdauer,
- keine öffentliche oder unbestimmt weite Zugänglichkeit,
- deaktivierte optionale Weitergabe, Verknüpfung, Analyse und Standortfunktion,
- zweckgebundene Benachrichtigungen und nachvollziehbare Wahlmöglichkeiten,
- keine vorangekreuzten oder irreführend gestalteten Optionen, soweit eine Einwilligung benötigt wird.
Eine Nutzerentscheidung wird nicht durch Dark Patterns, unnötige Wiederholungen oder schlechtere Alternativen erzwungen.
¶ 8. Gestaltungsstrategien
Geeignete Strategien können sein:
- Daten vermeiden, reduzieren, aggregieren oder früh löschen,
- Datenbestände, Zwecke und Zuordnungswissen trennen,
- synthetische Daten oder wirksame Pseudonymisierung einsetzen,
- lokale statt zentrale Verarbeitung nutzen, wenn angemessen,
- Zugriff, Sichtbarkeit und Weitergabe begrenzen,
- Transparenz, Kontrolle und Intervenierbarkeit technisch unterstützen,
- Regeln durch Konfiguration, Tests, Monitoring und Eskalation durchsetzen,
- Entscheidungen, Abweichungen und Wirksamkeit nachweisbar machen.
Die Auswahl richtet sich nach dem konkreten Risiko und darf keine neue unverhältnismäßige Belastung für betroffene Personen erzeugen.
¶ 9. Prüfregister
| Feld | Mindestinhalt |
|---|---|
| PbD-ID | eindeutige Kennung, zum Beispiel PBD-YYYY-NNN |
| Projekt / VVT | Projekt-, Produkt-, Änderungs- und Verarbeitungsreferenzen |
| Scope | Funktionen, Systeme, Daten, Personen, Standorte und Lieferanten |
| Anforderungen | prüfbare Sollanforderungen mit Rechts- und Risikoquelle |
| Voreinstellungen | dokumentierter Standardzustand und Begründung |
| DSFA-Status | Screening-ID, Entscheidung und gegebenenfalls DSFA-ID |
| Umsetzung | Soll-Ist-Status, Owner, Frist und Abweichungen |
| Test / Abnahme | Methode, Kriterium, Ergebnis, Datum und Prüfer |
| Restrisiko | verbleibende Risiken und befugte Entscheidung |
| Nachweisreferenz | geschützter Ablageort, Version und Schutzklasse |
| Review | Betriebskennzahlen, letzter und nächster Review, Änderungsauslöser |
¶ 10. Entwicklung, Beschaffung und Lieferanten
Datenschutzanforderungen werden Bestandteil von Leistungsbeschreibung, Auswahl, Vertrag, Architektur und Abnahme. Zu prüfen sind Konfigurierbarkeit, Datenexport, Löschung, Protokollierung, Mandantentrennung, Supportzugriffe, Unterauftragnehmer und Exit.
Herstellerangaben, Zertifikate oder Auftragsverarbeiterunterlagen unterstützen die Prüfung, ersetzen aber nicht die eigene Verantwortlichkeit und den konkreten Soll-Ist-Abgleich.
¶ 11. Test und Freigabe
Vor Inbetriebnahme werden risikobasiert geprüft:
- Datenfelder, Pflichtfelder, Schnittstellen und Datenflüsse,
- Rollen, Berechtigungen, Freigaben und Sichtbarkeit,
- Voreinstellungen nach Neuinstallation, Update und Rollenwechsel,
- Informationsbereitstellung und Betroffenenrechte,
- Aufbewahrung, Sperrung, Löschung und Wiederherstellung,
- Protokollierung, Alarmierung und Fehlerbehandlung,
- mobile Ansicht, API, Export, Suche und öffentliche Freigaben,
- Lieferanten-, Support- und Drittlandzugriffe.
Produktivdaten werden in Tests nur nach dokumentierter Ausnahme verwendet. Maßgeblich ist das Verfahren Testdaten, Anonymisierung und Pseudonymisierung.
¶ 12. Abweichungen und Ausnahmen
Eine Abweichung enthält Anforderung, Ursache, Risiko für betroffene Personen, Übergangsmaßnahme, Owner, Frist, Entscheidung und erneute Prüfung. Nicht erfüllte gesetzliche Anforderungen werden nicht durch allgemeine Risikoakzeptanz aufgehoben.
Kritische offene Punkte, ungeklärte Rechtsgrundlagen oder ein verbleibendes hohes Risiko ohne erforderliche Konsultation verhindern die Freigabe.
¶ 13. Betrieb, Änderungen und Außerbetriebnahme
Nach der Freigabe werden Voreinstellungen, Berechtigungen, Löschläufe, Betroffenenrechte, Vorfälle, Beschwerden und Wirksamkeitskennzahlen überwacht. Updates, neue Funktionen, Zweckänderungen, Schnittstellen und Lieferantenwechsel lösen ein erneutes Screening aus.
Bei Außerbetriebnahme werden Export, Aufbewahrung, Löschung, Backup, Schlüssel, Protokolle, Verträge und Nachweisaufbewahrung geplant und kontrolliert abgeschlossen.
¶ 14. Rollen
| Rolle | Aufgabe |
|---|---|
| Projekt-/Produkteigner | Scope, Ressourcen, Anforderungen und Umsetzung steuern |
| Prozesseigner | Zwecke, Erforderlichkeit, Fachprozess und VVT verantworten |
| Datenschutzkoordination | Verfahren, Register, Fristen und Schnittstellen koordinieren |
| Datenschutzbeauftragte/r | unabhängig beraten und überwachen, sofern benannt |
| Informationssicherheit / IT | Architektur, Bedrohungen, TOM und technische Tests bewerten |
| Entwicklung / Konfiguration | Anforderungen umsetzen, dokumentieren und Fehler beheben |
| Einkauf / Lieferantenmanagement | Anforderungen, Verträge, Nachweise und Exit steuern |
| befugte Leitung | Restrisiko und Freigabe im eigenen Mandat entscheiden |
¶ 15. Nachweise und Schutz
Geschützt aufbewahrt werden Anforderungen, Datenflussmodelle, Architekturentscheidungen, Testprotokolle, Screenshots, Konfigurationen, DSFA-Unterlagen, Abweichungen und Freigaben. Das öffentliche Wiki enthält nur Methodik, leere Struktur und kontrollierte Referenzen.
Ein Nachweis belegt nur den geprüften Umfang, Zeitpunkt und Zustand. Eine Projektfreigabe ist kein dauerhafter Wirksamkeitsnachweis.
¶ 16. Leeres Steuerungsregister
| PbD-ID | Projekt / VVT | Gate | Owner | Anforderungen / Voreinstellungen | DSFA | Status | Test / Abweichung | Freigabe | Review |
|---|---|---|---|---|---|---|---|---|---|
| – | – | – | – | – | – | – | Kein realer Eintrag im Muster-Wiki | – | – |
¶ 17. Qualitätskontrolle
- Wurde Datenschutz vor Festlegung der Mittel einbezogen?
- Sind Zwecke, Erforderlichkeit, Datenflüsse und Voreinstellungen konkret?
- Sind Anforderungen prüfbar und Verantwortlichen zugeordnet?
- Wurde das DSFA-Screening rechtzeitig durchgeführt?
- Sind Menge, Umfang, Dauer und Zugänglichkeit standardmäßig begrenzt?
- Stimmen Soll-Design, Konfiguration und reale Verarbeitung überein?
- Wurden Rechte, Löschung, Fehlerfälle und Lieferantenzugriffe praktisch getestet?
- Sind Abweichungen befristet, entschieden und erneut geprüft?
- Werden Änderungen und Wirksamkeit im Betrieb überwacht?
¶ 18. Verknüpfte Seiten
| Seite | Funktion |
|---|---|
| Verzeichnis von Verarbeitungstätigkeiten | führender Verarbeitungskontext |
| DSFA-Prüfregister | frühzeitiges Screening |
| Datenschutz-Folgenabschätzung | vertiefte Prüfung hoher Risiken |
| Technische und organisatorische Maßnahmen | Maßnahmen, Status und Wirksamkeit |
| Lösch- und Aufbewahrungskonzept | Fristen, Ereignisse, Löschung und Ausnahmen |
| Testdaten, Anonymisierung und Pseudonymisierung | Schutz in Entwicklung, Test und Analyse |
| ISMS Informationssicherheit im Projektmanagement | Sicherheitsanforderungen und Projekt-Gates |
| ISMS Sichere Entwicklung | Entwicklungs- und Freigabekontrollen |
¶ 19. Offizielle Grundlagen
- DSGVO, insbesondere Artikel 5, 24, 25, 32 und 35 – EUR-Lex
- EDSA-Leitlinien 4/2019 zu Artikel 25 – finale Fassung
- Datenschutzkonferenz: Standard-Datenschutzmodell Version 3.1
¶ 20. Weiterführende Informationen von SMCT MANAGEMENT
Unterstützung bei Datenschutzanforderungen, Projekt-Gates, DSFA, TOM und kontrollierten Freigaben
Erstgespräch unter info@smct-management.de vereinbaren
¶ 21. Änderungshistorie
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe |
|---|---|---|---|---|
| 0.1 | 08.08.2026 | Musterverfahren mit Artikel-25-Kriterien, Projekt-Gates, datenschutzfreundlichen Voreinstellungen, Prüfregister, Test, Abweichung und Lebenszyklus erstellt | Datenschutzkoordination / Musterrolle | Ausstehend |