Theorie ist das eine, ein konzernweiter Rollout das andere. In diesem anonymisierten Projektbericht beschreiben wir die Einführung von Microsoft Information Protection — heute Teil von Microsoft Purview — in einem DAX-Konzern mit über 100.000 Mitarbeitenden. Es war eines unserer ersten großen Klassifizierungsprojekte: Wir haben die Lösung dort bereits vor rund einem Jahrzehnt eingeführt, lange bevor sie den Namen Purview trug. Namen und Details sind anonymisiert, die Herausforderungen und Learnings sind real.
Ausgangslage
Der Kunde — ein global tätiger Pharma- und Life-Science-Konzern mit über 100.000 Mitarbeitenden — wollte die Klassifizierung und den Schutz sensibler Dokumente konzernweit auf eine zukunftsfähige, in Microsoft 365 integrierte Lösung stellen.
Die Besonderheit: Es gab bereits eine Klassifizierung. Über Jahre hatte das Unternehmen ein eigenentwickeltes Office-Add-in im Einsatz, mit dem Mitarbeitende ihre Dokumente kennzeichneten. Eine grüne Wiese war das also nicht — im Gegenteil. Tausende Mitarbeitende waren an ein bestimmtes Verfahren gewöhnt, und es existierten unzählige Bestandsdokumente mit den alten Kennzeichnungen. Jede neue Lösung musste diese Realität berücksichtigen.
Dazu kamen zwei erschwerende Faktoren: eine sehr komplexe, heterogene Systemlandschaft mit Daten in der Cloud und in zahlreichen On-Premise-Systemen — sowie strenge regulatorische Anforderungen, wie sie in der Pharma- und Life-Science-Branche üblich sind.
Phase 1: Migrationsstrategie
Der erste und wichtigste Schritt war keine technische, sondern eine konzeptionelle Frage: Wie löst man eine etablierte Eigenentwicklung ab, ohne die Belegschaft zu verlieren?
Wir haben eine Migrationsstrategie entwickelt, die das bestehende Add-in und die neuen Sensitivity Labels für eine Übergangszeit nebeneinander bestehen ließ und die alten Kennzeichnungen auf das neue Schema abbildete. So konnten Mitarbeitende schrittweise umsteigen, statt von einem Tag auf den anderen mit einem völlig neuen Verfahren konfrontiert zu werden — und die Bestandsdokumente verloren ihre Klassifizierung nicht.
Aus der Praxis: Die größte Hürde bei einer Ablösung ist selten die Technik, sondern die Gewohnheit. Wer eine funktionierende — wenn auch veraltete — Lösung ersetzt, braucht eine Brücke, keinen Sprung.
Phase 2: Taxonomie unter regulatorischem Druck
Die Definition des Klassifizierungsschemas war der intensivste Teil des Projekts. In einem Konzern dieser Größe hat jede Funktion eine eigene Sicht darauf, was schützenswert ist — und entsprechend viele Interessen mussten unter einen Hut.
Ein Beispiel, das viele überrascht: Das eigentlich naheliegende Label "Öffentlich" durfte auf ausdrücklichen Wunsch der Rechtsabteilung nicht verwendet werden. Die Sorge war, dass eine explizite Kennzeichnung als "öffentlich" in einem stark regulierten Umfeld rechtlich heikel werden könnte. Wir haben das Schema entsprechend ohne diese Stufe aufgebaut.
Für bestimmte, regulatorisch besonders sensible Bereiche haben wir dedizierte Labels mit eigenen Schutz- und Zugriffsregeln definiert — statt zu versuchen, sämtliche Anforderungen in ein einziges universelles Schema zu pressen.
Phase 3: Verschlüsselung mit Augenmaß
Verschlüsselung ist der stärkste Schutz, den Sensitivity Labels bieten — und gleichzeitig die größte Quelle für blockierte Arbeitsabläufe. Unser Leitsatz im gesamten Projekt: so einfach wie möglich, so sicher wie nötig.
Statt pauschal alles zu verschlüsseln, haben wir genau abgewogen, wo Verschlüsselung echten Mehrwert bringt und wo sie nur die Zusammenarbeit erschwert — gerade in einem Konzern, der intensiv mit externen Forschungs- und Entwicklungspartnern zusammenarbeitet. Volle Verschlüsselung kam gezielt dort zum Einsatz, wo der Schutzbedarf es zwingend erforderte.
Phase 4: Stakeholder, Proof of Concept und Pilotwellen
In einem Großkonzern entscheidet sich der Erfolg eines solchen Projekts nicht im Compliance Center, sondern in den Köpfen der Menschen. Entsprechend groß war der anfängliche Widerstand — Klassifizierung verändert den Arbeitsalltag jedes Einzelnen.
Wir haben sehr viele Stakeholder-Gespräche geführt, einen ausführlichen Proof of Concept aufgesetzt und mehrere Pilotwellen durchlaufen, bevor wir den unternehmensweiten Rollout starteten. Jede Welle lieferte Feedback, das direkt in die Konfiguration zurückfloss. Dieser iterative, dialogorientierte Ansatz war zeitaufwendig — aber er war der Grund, warum die Lösung am Ende akzeptiert und nicht umgangen wurde.
Aus der Praxis: Je größer die Organisation, desto mehr Zeit fließt in Kommunikation statt in Konfiguration. Wer hier spart, zahlt später mit Workarounds und Frust.
Phase 5: Default-Labels und Data at Rest
Ein universelles Standard-Label für alle hätte in einem so heterogenen Konzern nicht funktioniert. Wir haben deshalb dedizierte Default-Label-Einstellungen für unterschiedliche Nutzergruppen konfiguriert — passend zu den Daten, mit denen die jeweilige Gruppe typischerweise arbeitet.
Eine eigene Disziplin war der Schutz bestehender Daten (Data at Rest). Klassifizierung darf nicht nur für neue Dokumente greifen — die sensibelsten Informationen liegen oft seit Jahren in bestehenden Ablagen. Wir haben das nachträgliche Scannen und Klassifizieren von Bestandsdaten aufgesetzt, was in der beschriebenen Cloud- und On-Premise-Landschaft eine technische Herausforderung für sich war.
Lessons Learned
1. Eine bestehende Lösung braucht eine Migration, keinen Bruch. Wo schon klassifiziert wird — und sei es mit einer Eigenentwicklung — entscheidet eine saubere Migrationsstrategie über Akzeptanz und Datenkontinuität.
2. Die Taxonomie folgt dem Business und der Regulatorik, nicht dem Lehrbuch. Dass ausgerechnet "Öffentlich" entfallen würde, hätte kein Standardschema vorhergesehen. Das Schema muss gemeinsam mit Recht, Compliance und den Fachbereichen entstehen.
3. Verschlüsselung ist kein Schalter, sondern eine Abwägung. So einfach wie möglich, so sicher wie nötig — dieser Grundsatz schützt die Zusammenarbeit ebenso wie die Daten.
4. Default-Labels gehören pro Nutzergruppe gedacht. Ein einziges Standard-Label für einen ganzen Konzern erzeugt entweder Überklassifizierung oder ständiges manuelles Umlabeln.
5. Data at Rest nicht vergessen. Der größte ungeschützte Datenbestand liegt meist nicht in neuen, sondern in alten Dokumenten.
Fazit
Dieses Projekt war in vieler Hinsicht ein Extremfall: ein Konzern mit über 100.000 Mitarbeitenden, eine abzulösende Eigenentwicklung, strenge Regulatorik und eine komplexe Hybrid-Landschaft. Genau deshalb steckt darin so viel übertragbares Wissen.
Für mittelständische Unternehmen ist das die gute Nachricht: Die Mechanik ist dieselbe, die Komplexität deutlich geringer. Ein durchdachtes Schema, eine ehrliche Auseinandersetzung mit Verschlüsselung, dedizierte Default-Labels und ein dialogorientierter Rollout funktionieren bei 500 Nutzern genauso wie bei 100.000 — nur deutlich schneller.
Sie möchten wissen, wie ein Rollout in Ihrem Unternehmen aussehen könnte? Wir bringen die Erfahrung aus Großprojekten mit und passen den Ansatz an Ihre Größe und Ihre Anforderungen an.