Privacy mit NIST: das Privacy Framework und die PT-Familie

Problem in der Praxis

In vielen Organisationen laufen Datenschutz und Informationssicherheit auf getrennten Spuren. Die Sicherheit arbeitet entlang von CSF und SP 800-53, der Datenschutz entlang rechtlicher Vorgaben und Verfahrensverzeichnissen. Beide Welten begegnen sich erst im Vorfall oder im Audit, und dann oft mit unterschiedlicher Sprache, unterschiedlichen Risikobegriffen und ohne gemeinsames Steuerungsmodell.

Das führt zu wiederkehrenden Mustern: Privacy-Risiken werden ausschließlich als Schutzverletzung gedacht, obwohl die eigentliche Frage häufig Zweckbindung, Datenminimierung oder fehlende Transparenz gegenüber den Betroffenen ist. Verantwortlichkeiten sind unscharf; niemand kann sagen, wer den Privacy-Risikoappetit festlegt. Maßnahmen werden punktuell aus rechtlichen Anlässen getrieben statt aus einer kohärenten Risikostrategie. Und die Brücke zur Sicherheit, dort wo Schutzmaßnahmen tatsächlich Privacy stützen, bleibt unbenannt: dieselbe Kontrolle wird in zwei getrennten Systemen doppelt oder gar nicht verwaltet.

CISO-Einordnung

Das NIST Privacy Framework ist die strukturelle Antwort auf diese Trennung. Es ist eigenständig, aber so konstruiert, dass es sich mit dem Cybersecurity Framework kombinieren lässt: gleiche Logik, kompatibles Vokabular. Wie das CSF arbeitet es mit einem Core aus Functions, Categories und Subcategories, mit Profiles zur Ist-/Soll-Bestimmung und mit Implementation Tiers zur Einschätzung der Reife des Privacy-Risikomanagements.

Die fünf Functions bilden den Steuerungskreis für Datenschutz. Identify-P schafft das Verständnis für Datenverarbeitung und die damit verbundenen Privacy-Risiken. Govern-P verankert Strategie, Rollen, Policy und Aufsicht, das Pendant zur Steuerungslogik, die das CSF 2.0 mit seiner Govern-Function ins Zentrum stellt. Control-P adressiert das Management der Verarbeitung selbst: Datenminimierung, Zweckbindung und gezielte Steuerbarkeit. Communicate-P sorgt für Transparenz und Dialog mit Betroffenen und Stakeholdern. Protect-P umfasst die Schutzmaßnahmen und überschneidet sich bewusst mit der Protect-Function des CSF.

Wer diese Outcomes mit konkreten Kontrollen unterlegen will, findet die Tiefe in SP 800-53 Rev. 5 (20 Familien, 324 Basis-Controls, 872 Enhancements). Für Privacy ist die Familie PT (Personally Identifiable Information Processing and Transparency) zentral, mit acht Basis-Controls von PT-1 (Policy and Procedures) bis PT-8 (Computer Matching Requirements), darunter Authority to Process, Processing Purposes, Consent, Privacy Notice und System of Records Notice. SP 800-53 führt damit Sicherheits- und Privacy-Controls in einem Katalog; die Companion-Publikation SP 800-53B liefert neben den Sicherheitsbaselines eine eigene Privacy-Baseline.

Umsetzungsperspektive

Das Privacy Framework lässt sich nicht durch ein Dokument erfüllen, sondern wie das CSF über Profiles und wiederkehrende Steuerung. Bewährt hat sich, die fünf Functions als zusammenhängendes Arbeitsprogramm mit klaren Eigentümern zu lesen.

• Identify-P: Datenverarbeitungen inventarisieren, Datenflüsse und betroffene Personengruppen verstehen, Privacy-Risiken aus der Verarbeitung selbst ableiten, nicht nur aus möglichen Sicherheitsverletzungen.
• Govern-P: Privacy-Risikostrategie, Risikoappetit, Rollen und Policies durch die Leitung verankern; Aufsicht und Reviewzyklen etablieren. Hier lässt sich die Steuerung eng mit der CSF-Govern-Function verzahnen.
• Control-P: Datenminimierung und Zweckbindung operativ verankern, Lösch- und Korrekturfähigkeit sicherstellen, Verarbeitung gezielt steuerbar machen.
• Communicate-P: Transparenz herstellen, mit Privacy Notices, verständlichen Informationen sowie Auskunfts- und Dialogfähigkeit gegenüber Betroffenen.
• Protect-P: Schutzmaßnahmen umsetzen und dabei die Überschneidung mit der CSF-Protect-Function nutzen, statt Kontrollen doppelt zu führen.

Ein pragmatischer Einstieg ist ein kombiniertes Profile: ein gemeinsames Soll-Bild für Sicherheit (CSF) und Datenschutz (Privacy Framework), in dem geteilte Kontrollen, insbesondere im Protect-Bereich, nur einmal definiert und gemeinsam verwaltet werden. Die PT-Familie aus SP 800-53 dient dabei als Kontrollreservoir, wenn Privacy-Outcomes nachweisbar unterlegt werden sollen.

Typische Fehler

1. Privacy wird ausschließlich als Vertraulichkeitsthema verstanden. Risiken aus Zweck, Umfang und Transparenz der Verarbeitung selbst bleiben unbeachtet.
2. Privacy Framework und CSF werden als konkurrierende statt komplementäre Werkzeuge behandelt; die bewusste Überschneidung bei Protect-P wird nicht genutzt.
3. Govern-P wird übersprungen: Es gibt kein formales Mandat und keinen beschlossenen Privacy-Risikoappetit, sodass jede Priorisierung verhandelbar bleibt.
4. Geteilte Kontrollen werden doppelt geführt, einmal im Sicherheits-, einmal im Datenschutzsystem, mit widersprüchlichen Nachweisen.
5. Das Framework wird wie ein zertifizierbarer Standard behandelt. Es liefert Outcomes und Steuerungslogik, keinen Konformitätsnachweis und keinen Rechtsrahmen.

Risiken und Trade-offs

Der erste Trade-off betrifft die Abgrenzung von Sicherheit und Datenschutz. Eine zu enge Kopplung lässt Privacy in der Sicherheit aufgehen und blendet verarbeitungsbedingte Risiken aus; eine zu starke Trennung erzeugt Doppelarbeit, widersprüchliche Kontrollen und Reibung. Die bewusste Überschneidung von Protect-P und CSF-Protect ist der von NIST vorgesehene Mittelweg, sie muss aber aktiv gestaltet werden.

Der zweite Trade-off betrifft Tiefe und Tempo: Eine vollständige Profile-Erstellung über alle fünf Functions ist gründlich, aber langsam; eine risikobasierte Staffelung zuerst der Verarbeitungen mit hohem Privacy-Risiko liefert schneller Wirkung, verlangt aber eine belastbare Priorisierung aus Identify-P. Drittens bleibt die Rechtsperspektive: Das Framework ist ein Risikomanagement-Werkzeug, kein Ersatz für die rechtliche Bewertung. Wer es als Compliance-Beleg missversteht, schafft trügerische Sicherheit.

Entscheidungspunkte

• Behandeln wir Datenschutz und Sicherheit in getrennten Modellen oder in einem kombinierten CSF-/Privacy-Framework-Profile?
• Wer in der Leitung verantwortet Privacy-Risiko (Govern-P), und ist ein Privacy-Risikoappetit formal beschlossen?
• Welche Kontrollen teilen sich Sicherheit und Datenschutz (Protect-P / CSF-Protect), und wie verwalten wir sie genau einmal?
• Welche Privacy-Outcomes unterlegen wir mit Controls aus der PT-Familie von SP 800-53, und wo bleibt es bei Outcome-Steuerung?
• Warten wir auf das Privacy Framework v1.1 oder starten wir mit v1.0 und richten uns später aus?

Praktische Empfehlungen

1. Lesen Sie das Privacy Framework als Ergänzung des CSF, nicht als Parallelwelt: ein gemeinsames Profile, geteilte Kontrollen genau einmal definiert.
2. Verankern Sie Govern-P zuerst, mit Mandat, Privacy-Risikoappetit, Rollen und Aufsicht, bevor Sie in operative Maßnahmen investieren.
3. Leiten Sie Privacy-Risiken in Identify-P aus der Verarbeitung selbst ab (Zweck, Umfang, Transparenz, Kontrolle), nicht nur aus Schutzverletzungen.
4. Nutzen Sie die PT-Familie aus SP 800-53 Rev. 5 als Kontrollreservoir, wenn Privacy-Outcomes nachweisbar unterlegt werden müssen; die Privacy-Baseline in SP 800-53B gibt Orientierung.
5. Planen Sie die Ausrichtung an Privacy Framework v1.1 ein, das sich am CSF 2.0 orientiert, aber starten Sie nicht erst mit dessen Erscheinen; v1.0 ist tragfähig.

Relevante Normreferenzen

• NIST Privacy Framework v1.0 (Januar 2020): fünf Functions Identify-P, Govern-P, Control-P, Communicate-P, Protect-P; Core, Profiles und Implementation Tiers; v1.1 in Entwicklung, an CSF 2.0 ausgerichtet. Public Domain.
• NIST CSF 2.0 (NIST.CSWP.29, 26.02.2024): kompatibles Rahmenwerk; Überschneidung von Protect-P mit der CSF-Protect-Function. Public Domain.
• NIST SP 800-53 Rev. 5: Kontrollkatalog mit der Privacy-Familie PT (Personally Identifiable Information Processing and Transparency), acht Basis-Controls PT-1 bis PT-8. Public Domain.
• NIST SP 800-53B: Control Baselines inklusive Privacy-Baseline. Public Domain.