DSGVO im Anforderungsmanagement: 7 Prüfpunkte
Der teuerste Datenschutzfehler entsteht nicht im Betrieb einer Software, sondern in ihrer Anforderungsphase. Wer personenbezogene Daten erst in der Umsetzung mitdenkt, hat die DSGVO strukturell verloren — Artikel 25 verlangt Datenschutz durch Technikgestaltung, also bevor die erste Zeile Code entsteht. Dieser Beitrag zeigt, wie Sie Anforderungsmanagement so aufsetzen, dass DSGVO-Konformität nicht nachträglich nachgerüstet wird, sondern von Anfang an Teil jeder Anforderung ist.
Warum DSGVO im Anforderungsmanagement beginnt
Datenschutz beginnt nicht bei der Datenschutzerklärung. Er beginnt beim Datenmodell, bei der Zugriffsarchitektur und bei den Löschroutinen — und damit bei den Anforderungen, die dem Entwicklungsteam vorgelegt werden.
Artikel 25 der DSGVO verpflichtet Verantwortliche zu Datenschutz durch Technikgestaltung (Privacy by Design) und datenschutzfreundlichen Voreinstellungen (Privacy by Default). Das ist keine Empfehlung, sondern eine bußgeldbewehrte Pflicht. Aufsichtsbehörden verhängen bei Verstößen regelmäßig zusätzliche Bußgelder gegen Artikel 5 (Grundsätze) und Artikel 32 (Sicherheit der Verarbeitung).
Der Punkt ist: All diese Artikel richten sich an den Verantwortlichen. Wenn dieser eine Software beauftragt, deren Anforderungen den Datenschutz erst am Ende mitdenken, hat er die Compliance-Pflicht bereits verletzt — unabhängig davon, ob es später zu einem Vorfall kommt.
Für Anforderungsingenieure heißt das: Jede Anforderung, die personenbezogene Daten berührt, ist gleichzeitig eine Compliance-Anforderung. Das gilt für alle Systeme mit Kundendaten, HR-Daten, Gesundheitsdaten, Zahlungsdaten oder Telemetrie — in der Praxis für nahezu jedes Enterprise-System in Deutschland.
Fakt: Nach Artikel 25 DSGVO müssen technische und organisatorische Datenschutzmaßnahmen bei der Festlegung der Mittel der Verarbeitung implementiert sein — also in der Konzeptionsphase. Wer erst nach der Implementierung prüft, ist zu spät.
Die relevanten DSGVO-Artikel für Anforderungen
Vier Artikel der DSGVO sind für Anforderungsmanagement direkt handlungsleitend. Wer diese vier kennt, hat das Wesentliche.
Artikel 5 — Grundsätze: Rechtmäßigkeit, Zweckbindung, Datenminimierung, Speicherbegrenzung, Integrität und Rechenschaftspflicht. Jede Anforderung, die Daten erhebt oder verarbeitet, muss sich einem dieser Grundsätze zuordnen lassen.
Artikel 25 — Privacy by Design und by Default: Datenschutz muss in die Technik eingebaut sein, nicht daran angebaut. Voreinstellungen müssen die datenschutzfreundlichste Option sein.
Artikel 32 — Sicherheit der Verarbeitung: Verschlüsselung, Pseudonymisierung, Zugriffskontrollen, regelmäßige Prüfung. Das sind technische Anforderungen — sie gehören in die Spezifikation, nicht in die Betriebsphase.
Artikel 35 — Datenschutz-Folgenabschätzung (DSFA): Bei hohem Risiko für Betroffene ist eine formale Bewertung vor der Verarbeitung Pflicht. Der Trigger dafür entsteht im Anforderungsmanagement — Sie brauchen einen Mechanismus, der ihn erkennt.
Ergänzend gelten für die technische Umsetzung Normen wie ISO/IEC 25010 (Qualitätsmodell für Software, inkl. Security und Privacy) und ISO/IEC/IEEE 29148 (Anforderungsengineering, Definition of Ready). Beide sind bei Anforderungen nutzbar, um DSGVO-Vorgaben in prüfbare Kriterien zu übersetzen.
Sieben Punkte, die jede Anforderung bestehen muss
Eine praktikable DSGVO-Prüfung im Anforderungsmanagement kommt mit sieben Fragen aus. Ist nur eine unbeantwortet, ist die Anforderung nicht entscheidungsreif.
Rechtsgrundlage: Auf welcher Grundlage (Art. 6 DSGVO) werden die Daten verarbeitet — Einwilligung, Vertrag, berechtigtes Interesse, gesetzliche Pflicht?
Zweck: Ist der Verarbeitungszweck präzise benannt, oder steht dort "zur Nutzung der Anwendung"? Vage Zwecke sind DSGVO-widrig.
Datenminimierung: Werden wirklich nur die Daten erhoben, die für den Zweck notwendig sind? Das Wort "optional" ist hier eine Warnung, kein Freibrief.
Speicherdauer: Wann werden die Daten gelöscht oder anonymisiert? Ohne Löschkonzept ist die Anforderung nicht vollständig.
Zugriff und Rollen: Wer sieht was? Rollenkonzepte gehören in die funktionale Anforderung, nicht in die IT-Security-Abteilung.
Betroffenenrechte: Wie werden Auskunft (Art. 15), Berichtigung (Art. 16), Löschung (Art. 17) und Datenübertragbarkeit (Art. 20) technisch umgesetzt? Diese Rechte sind Features, die spezifiziert werden müssen.
DSFA-Trigger: Erzeugt die Anforderung eine Verarbeitung mit hohem Risiko (Profiling, sensible Daten, große Datenmengen)? Wenn ja, ist die DSFA nach Art. 35 vor dem Sprint-Start fällig.
Diese sieben Punkte sind kein Papierkram. Sie sind das Quality Gate, das darüber entscheidet, ob eine Anforderung überhaupt in die Umsetzung darf. Fehlt eines der sieben Kriterien, ist die Rework-Wahrscheinlichkeit hoch — und im schlimmsten Fall wird das Bußgeld später teurer als das Feature.
Fakt: Die Datenschutz-Grundsätze aus Artikel 5 DSGVO — Zweckbindung, Datenminimierung, Speicherbegrenzung — sind gleichzeitig gute Anforderungskriterien. Wer sie systematisch prüft, schreibt automatisch bessere Anforderungen, unabhängig vom Datenschutz.
Wie KI im Anforderungsmanagement DSGVO-konform bleibt
KI-Systeme im Anforderungsmanagement stehen unter besonderer Beobachtung, weil sie oft mit personenbezogenen oder vertraulichen Inhalten arbeiten. Der Fachverband IREB hat in seinem AI-Booklet einen zentralen Punkt formuliert, der hier direkt greift: Validierung ist Pflicht. KI-Ergebnisse sind Vorschläge, keine Wahrheiten. Wer sie ungeprüft in Anforderungsdokumente übernimmt, überträgt Verantwortung an ein System, das sie nicht tragen kann.
Für den Einsatz von KI im Anforderungsmanagement bedeutet DSGVO-Konformität drei Dinge:
Erstens: Datenherkunft und Verarbeitungsort müssen bekannt und dokumentiert sein. Ein US-basierter LLM-Dienst, der Fachanforderungen mit personenbezogenen Beispielen verarbeitet, ist ein Auftragsverarbeitungsverhältnis nach Art. 28 DSGVO — mit allen dazugehörigen Pflichten.
Zweitens: Trainings- und Kontextdaten dürfen keine personenbezogenen Daten enthalten, die außerhalb des Zwecks liegen. Das ist besonders bei Legacy-Anforderungen relevant, in denen echte Nutzernamen oder E-Mail-Adressen als Beispiele stehen.
Drittens: Menschliche Kontrolle muss dokumentierbar sein. Nach Art. 22 DSGVO haben Betroffene das Recht, nicht ausschließlich automatisierten Entscheidungen unterworfen zu werden — was für Anforderungen selbst nicht direkt gilt, aber für alle darauf aufbauenden Systeme.
NanoVerse AI ist genau für diesen Kontext gebaut. Die Plattform macht Anforderungen prozesstreu, relevant und entscheidungsreif — mit Betrieb in europäischer Infrastruktur, dokumentierter Auftragsverarbeitung und einer Architektur, in der die menschliche Freigabe kein optionaler Schritt ist, sondern integraler Bestandteil des Prozesses.
Was jetzt zu tun ist
DSGVO-konformes Anforderungsmanagement ist keine juristische Übung, sondern eine handwerkliche. Es entsteht dort, wo Anforderungen entstehen — und es scheitert dort, wo Datenschutz erst nach der Freigabe drankommt.
Der erste konkrete Schritt: Prüfen Sie Ihr eigenes Quality Gate. Enthält es die sieben Punkte oben? Wenn nein, ist genau das der Ort, an dem Ihr Compliance-Risiko strukturell entsteht — und der einzige Ort, an dem es sich strukturell beheben lässt.
Wie das in Ihrem Prozess konkret aussieht, zeigen wir am besten am eigenen Beispiel: Demo anfragen.
