Mehrere Betreiber, eine Leitung
An einer Hochschule können mehrere Stellen IT betreiben: das Rechenzentrum oder die zentrale IT mit Netz, Identitätsmanagement und Campus-Management, die Verwaltung mit Finanz- und Personalsystemen, Fakultäten und Institute mit eigenen Servern, Poolräumen und Webseiten, Forschungsgruppen mit Projektservern, Laborrechnern und Großgeräten. Das IT-Grundschutz-Profil für Hochschulen richtet sich ausdrücklich an Verantwortliche, „die sich aufgrund der oft dezentralen IT-Strukturen an Hochschulen mit Informationssicherheit beschäftigen“ (Profil Kap. 7.1).
Grundschutz++ gibt für diese Lage drei Werkzeuge. Erstens legt die Institutionsleitung den Anwendungsbereich fest; er „kann somit die gesamte Institution oder einen Teilbereich umfassen“, ausgeschlossene Bereiche können benannt werden (300-1 Kap. 2.3). Zweitens kann ein Anwendungsbereich „einen oder mehrere Informationsverbünde enthalten“ (Kap. 3.1), gegliedert nach organisatorischen Strukturen oder gemeinsamen Geschäftsprozessen. Drittens sind die Schnittstellen zwischen Informationsverbünden und zu externen Systemen eindeutig zu dokumentieren, organisatorisch, technisch und infrastrukturell (Kap. 3.1).
Die Verantwortung für die Umsetzung eines ISMS liegt nach Kapitel 2.10 bei der Institutionsleitung „und kann nicht delegiert werden“. Sie gilt für den ganzen Anwendungsbereich, auch für die Teile, die eine Fakultät selbst betreibt. Wer an Ihrer Hochschule Institutionsleitung ist, ergibt sich aus dem für sie geltenden Recht; das prüft diese Seite nicht.
Abgrenzungsmatrix: zentrale IT, Fakultäten, Forschung
Die Matrix ordnet sieben Bereiche einer fiktiven Universität. Für jeden Bereich nennt sie, wer betreibt und wer fachlich verantwortlich ist, die Option im Anwendungsbereich, die wir als Ausgangspunkt vorschlagen, und die Schnittstelle, die Sie dokumentieren. Die Trennung von Betrieb und fachlicher Verantwortung stützt sich auf die Methodik-Anforderung STM.2.1.2 im Anwenderkatalog; laut Erläuterung wird jedem Asset eine verantwortliche Rolle oder ein Asset-Owner zugewiesen. Die Optionen sind: A im zentralen Informationsverbund, B eigener Informationsverbund im selben Anwendungsbereich, C ausgeschlossen, mit dokumentierter Schnittstelle. Welche Option passt, entscheidet die Hochschulleitung auf Grundlage des Schutzbedarfs und der Zuständigkeiten.
| Bereich | Beispiele (fiktiv) | Wer betreibt | Fachlich verantwortlich (Beispiel) | Vorgeschlagene Option | Schnittstelle, die Sie dokumentieren | Fundstelle |
|---|---|---|---|---|---|---|
| Zentrale IT, Rechenzentrum | Campusnetz, WLAN, Identitätsmanagement, E-Mail, Campus-Management, Lernplattform | zentrale IT | Leitung der zentralen IT; für Campus-Management die Studierendenverwaltung | A | Dienste, die Fakultäten und Projekte nutzen: Netzübergänge, Anmeldung, zentrale Datensicherung | 300-1 Kap. 2.3, 3.1 |
| Hochschulverwaltung | Haushalt, Personal, Beschaffung | zentrale IT, Fachabteilungen | Leitung der jeweiligen Fachabteilung | A, bei eigenem Betrieb B | Anbindungen an externe Verfahren und Netze, etwa des Landes | 300-1 Kap. 3.1; Profil Kap. 9.4 |
| Fakultät oder Institut mit eigener IT | Institutsserver, Poolräume, eigene Webseiten, eigene Administrierende | Fakultät | Dekanat oder Institutsleitung | B, kleinere Einheiten A | Netzübergang zum Campusnetz, Nutzung des zentralen Identitätsmanagements, Rollen der dezentralen Administrierenden | 300-1 Kap. 2.8, 3.1 |
| Forschungsprojekt mit vertraglichen Auflagen | Projektserver, Datenaustausch mit Partnern, personenbezogene Studiendaten | Forschungsgruppe, ggf. zentrale IT | Projektleitung | B | Verpflichtungen aus Projektverträgen, Zugänge der Partner, Ende des Projekts mit Archivierung und Löschung | 300-1 Kap. 2.2, 2.6 |
| Forschungsinfrastruktur und Laborsteuerungen | Großgeräte, Messrechner, Gebäudeautomation der Labore | Forschungsgruppe, Haustechnik, Hersteller | Leitung der Arbeitsgruppe oder der zentralen Einrichtung | B oder C | Netzsegmente, Fernwartung der Hersteller, Übergang zu Speicher- und Rechendiensten | 300-1 Kap. 2.11, 3.4.3; Katalog ARCH.2.2.5 |
| Bezogene externe Dienste | Cloud-Dienste, Dienste eines Hochschulverbunds, Rechenzentrum einer Partnerhochschule | Anbieter außerhalb der Hochschule | Stelle, die den Dienst bezieht | Der bezogene Dienst steht in A oder B als Asset der Kategorie Outsourcing oder Cloud-Dienste; der Anbieter selbst liegt außerhalb | Vertrag, Nachweise, geteilte Verantwortung | 300-1 Kap. 3.1, Anhang 1 |
| Universitätsklinikum | Krankenhausinformationssystem, Medizintechnik | Klinikum | Leitung des Klinikums | C aus Sicht der Hochschule, wenn das Klinikum ein eigenes ISMS führt | gemeinsam genutzte Netze, Identitäten von Personen mit Rollen in Hochschule und Klinikum, Forschungsdaten aus der Versorgung | 300-1 Kap. 2.3, 3.1 |
Die Zuordnung der Optionen ist unsere Einschätzung; in Ihrem Fall bestimmen Zuständigkeiten, Verträge und die Rechtsform der Beteiligten, die wir nicht auslegen. Der Ausschluss aus dem Anwendungsbereich ändert die organisatorische und rechtliche Zugehörigkeit eines Bereichs nicht; er liegt nur außerhalb des ISMS. Seine Schnittstellen zum Anwendungsbereich dokumentieren Sie wie Schnittstellen zu externen Prozessen und Systemen (300-1 Kap. 3.1). Für das Klinikum beschreibt die Seite IT-Grundschutz im Krankenhaus die Abgrenzung aus Sicht des Klinikums. Wie Sie einen Informationsverbund allgemein abgrenzen, steht auf der Seite Informationsverbund abgrenzen.
Das IT-Grundschutz-Profil für Hochschulen: was es abdeckt und wo es aufhört
Das BSI veröffentlicht unter seinen IT-Grundschutz-Profilen ein Profil für Hochschulen, verfasst vom Arbeitskreis Informationssicherheit des Vereins „Zentren für Kommunikation und Informationsverarbeitung in Lehre und Forschung“ (ZKI), Version 2022.0.0, laut Profil veröffentlicht am 04.08.2022; die BSI-Seite zum Profil nennt das Datum 15.12.2022. Laut BSI-Seite entstand es im Rahmen der Mitgliedschaft des ZKI in der Allianz für Cybersicherheit auf Basis mehrerer Workshops unter Leitung des BSI. IT-Grundschutz-Profile beschreibt das BSI als „Muster für Sicherheitskonzepte, die anhand eines Anwendungsbeispiels die IT-Grundschutz Vorgehensweise darstellen“.
Das Profil betrachtet fünf Geschäftsprozesse: übergreifende Anwendungen, Bewerbung und Zulassung, Immatrikulation und Studierendenmanagement, Prüfungen und IT-Infrastruktur für Studierende (Profil Kap. 7.3, 9.1). Es konzentriert sich damit auf die Lehre. Für Forschung und Verwaltung hält es selbst fest, dass „Anforderungen der Zentralverwaltung und der Forschung zu evaluieren“ sind und dass spezielle Anforderungen der Forschungsumgebungen „mit den dort abgewickelten Projekten“ variieren (Kap. 9.4). Beim Schutzbedarf gehen die Autorinnen und Autoren meist von „normal“ aus und setzen ihn an ausgewählten Stellen auf „hoch“, etwa bei Immatrikulation und Studierendenmanagement für die Vertraulichkeit und bei Prüfungen für Vertraulichkeit und Integrität (Kap. 8.2).
Methodisch steht das Profil auf dem klassischen IT-Grundschutz: Es verwendet die Basis- und Standard-Absicherung nach BSI-Standard 200-2 (Kap. 8.3) und kommentiert Bausteine des IT-Grundschutz-Kompendiums in der Edition 2022. Eine Fassung für Grundschutz++ haben wir in den ausgewerteten Quellen (Stand 1. November 2026) nicht gefunden. Die Zuordnung des Kompendiums zu Grundschutz++ in der Stand-der-Technik-Bibliothek bezieht sich auf die Edition 2023 und steht auf Status „draft“.
Für die Arbeit mit Grundschutz++ heißt das:
- Prozessauswahl übernehmen: Die fünf Prozesse des Profils sind ein brauchbarer Startpunkt für die Liste der Geschäftsprozesse nach 300-1 Kap. 2.5. Forschung, Verwaltung und Weiterbildung ergänzen Sie selbst.
- Schutzbedarf neu begründen: Die Einstufungen des Profils sind Vorschläge für drei Kategorien nach 200-2. Grundschutz++ kennt zwei Kategorien, „normal“ und „hoch“ (300-1 Kap. 2.6); jede Einstufung gibt die Hochschulleitung frei (Kap. 2.10).
- Bausteinkommentare als Umsetzungshinweise lesen: Die Kommentare beziehen sich auf Bausteine der Edition 2022. Für das Anforderungspaket nach Grundschutz++ ordnen Sie Assets den Zielobjektkategorien zu (Kap. 3.4.2) und prüfen jede Übernahme einzeln. Wie Sie Zuordnungen aus dem Mapping prüfen, beschreibt die Seite Mapping IT-Grundschutz 2023 prüfen.
- Vorgehensweisen nicht vermischen: Basis- und Standard-Absicherung gibt es in 300-1 nicht. Die Unterschiede beschreibt die Seite Basis-, Kern- und Standard-Absicherung; die Abwägung, ob und wann Sie umsteigen, die Seite Umstieg entscheiden.
Unter den veröffentlichten Profilen führt das BSI außerdem ein IT-Grundschutz-Profil Ressort-Forschungseinrichtungen (Arbeitskreis Ressort Forschungseinrichtungen, Version 1.0). Ob es für eine Hochschule passt, prüfen Sie an seinem eigenen Geltungsbereich.
Forschung abgrenzen: Projekte, Verträge und Geräte
Forschung lässt sich in Grundschutz++ wie jeder andere Bereich über Geschäftsprozesse abbilden. Ein Forschungsprojekt mit eigenen Daten, Partnern und Laufzeit ist ein Kandidat für einen eigenen Geschäftsprozess mit eigenem Schutzbedarf. Stammen Vorgaben aus einem Projekt- oder Fördervertrag, sind es vertragliche Verpflichtungen; 300-1 Kapitel 2.2 sieht vor, dass sie zusammengestellt werden, und sie ergänzen das Anforderungspaket (Kap. 3.4.3). Hat ein Projekt bei mindestens einem Schutzziel hohen Schutzbedarf, ist eine explizite Risikobetrachtung erforderlich (Kap. 2.11), und die Abhängigkeiten der Assets zum Prozess sind zu dokumentieren (Kap. 3.2).
Großgeräte, Messrechner und Laborsteuerungen werfen eine zweite Frage auf. Anhang 1 von 300-1 kennt keine eigene Zielobjektkategorie für Forschungsgeräte; vernetzte Geräte lassen sich der Kategorie IT-Systeme zuordnen. Der Katalog verlangt, Verbindungen zwischen OT-Systemen und anderen IT-Systemen einzuschränken (ARCH.2.2.5, SOLLTE); die Erläuterung nennt industrielle Steuerungssysteme und Gebäudeautomation als Beispiele. Deckt der Katalog ein Gerät nicht hinreichend ab, folgt nach Kapitel 2.11 eine explizite Risikobetrachtung, und Sie formulieren ergänzende Anforderungen. Kann eine Anforderung an einem Gerät funktional nicht erfüllt werden, ist „nicht anwendbar“ zulässig, mit dokumentierter Begründung (Kap. 4.1.1).
Für ein Projekt mit Laufzeit gehört das Ende in die Planung: Partnerzugänge, Projektkonten und Daten. Der Katalog verlangt eine Vorgehensweise für den Weggang von Nutzenden (PERS.6.1, SOLLTE) und die Deaktivierung der Identität bei Weggang (BER.2.5, SOLLTE); die Erläuterung zu BER.2.5 versteht unter Weggang die nicht nur kurzfristige Beendigung der Aktivitäten, etwa durch Kündigung, Elternzeit oder Sabbatical. Endet nur eine Rolle, etwa die Mitarbeit in einem Projekt, während die Person beschäftigt oder eingeschrieben bleibt, entziehen Sie die projektbezogenen Berechtigungen und lassen die Identität bestehen; dafür verlangt der Katalog eine Vorgehensweise zum Entzug von Berechtigungen (BER.4.8, SOLLTE). Zum Projektende gehört außerdem die Übergabe von Repositorien, Software und Datenzugängen, die weiter gebraucht werden, an eine dauerhaft verantwortliche Stelle; das ist unser Vorschlag. Exportkontrolle, Forschungsdatenmanagement und Datenschutz bei Studiendaten sind eigene Rechtsgebiete; diese Seite behandelt sie nicht.
Studierende, Gäste und wechselndes Personal
Grundschutz++ fasst unter „Nutzende“ alle natürlichen Personen, die regelmäßig Assets im Informationsverbund für die Institution benutzen können, „unabhängig davon ob sie aus Sicht der Institution intern oder extern sind“ (300-1 Anhang 1). Für eine Hochschule gehören damit Studierende, Lehrbeauftragte, Gastwissenschaftlerinnen und Gastwissenschaftler und Projektpartner mit Zugang in den Blick, neben den Beschäftigten. Im Anwenderkatalog (Build 2026-10-29) sind nach unserer Zählung 81 Anforderungen der Zielobjektkategorie Nutzende direkt zugeordnet, 11 der Kategorie Mitarbeitende.
Das Hochschulprofil führt in seiner Referenzarchitektur unter den übergreifenden Anwendungen auch Remote-Zugang über WLAN und eduroam sowie VPN (Profil Kap. 10.1.1). Die Tabelle nennt Anforderungen des Anwenderkatalogs, die bei offenen Netzen, Gästen und wechselnden Personen ansetzen.
| Kennung | Titel | Modalverb | Bezug an der Hochschule (unsere Einordnung) |
|---|---|---|---|
| ARCH.2.1 | Netzsegmente | SOLLTE | Campusnetz nach Anforderungen und Schutzbedarf unterteilen, etwa Verwaltung, Lehre, Forschung, Geräte |
| ARCH.2.2.2 | Gastnetz | SOLLTE | Verbindungen zwischen Gastnetz und internem Netz einschränken; die Erläuterung nennt Besprechungs-, Veranstaltungs- und Schulungsräume |
| ARCH.2.2.5 | OT-Systeme | SOLLTE | Verbindungen zwischen Laborsteuerungen, Gebäudeautomation und übrigem Netz einschränken |
| ASST.2.2 | Inventar der Systeme | SOLLTE | Inventar mit Identifikationsbezeichnung und letztem bekanntem Verbleib, auch für Geräte der Institute |
| SENS.2.4 | Nutzung unautorisierter Assets | SOLLTE | Nutzung nicht freigegebener Systeme, Datenträger und Cloud-Dienste untersagen; laut Erläuterung gegen Schatten-IT |
| PERS.6.1 | Vorgehensweise für den Weggang | SOLLTE | Ende von Verträgen, Projekten und Gastaufenthalten geregelt abwickeln |
| BER.2.5 | Deaktivierung bei Weggang | SOLLTE | Identitäten bei Weggang deaktivieren, auch nach befristeten Verträgen und Gastaufenthalten; endet nur eine Rolle, Berechtigungen nach BER.4.8 entziehen |
Für eigene Geräte von Studierenden und Beschäftigten gilt der Maßstab der Methodik-Anforderung STM.2.1.2 (MUSS): festzulegen sind alle relevanten Assets für die betrachteten Geschäftsprozesse. Private Nutzung bleibt außen vor; nutzt ein Prozess eigene Geräte, etwa eine elektronische Prüfung auf Geräten der Studierenden oder den Zugriff auf Forschungsdaten von privaten Rechnern, bewerten Sie Datenzugriffe, Anforderungen und Kontrollmöglichkeiten für diesen Prozess. Das Netz, in das sich die Geräte einbuchen, und die Dienste, die sie nutzen, gehören in jedem Fall dazu. Wie Sie Eintritt, Wechsel und Austritt mit Berechtigungen verbinden, zeigt die Seite Praxis: Berechtigungen und Personal; Unterweisungen für sehr unterschiedliche Gruppen die Seite Praxis: Sensibilisierung.
Rollen zwischen Hochschulleitung, zentraler IT und Fakultäten
Kapitel 2.8 von 300-1 verlangt eine Informationssicherheitsorganisation mit festgelegten Rollen und Zuständigkeiten, die Vermeidung von Interessenkonflikten, ausdrücklich zwischen IT-Leitung und ISB sowie zwischen DSB und ISB, und die Festlegung von Schnittstellen innerhalb des Anwendungsbereichs. Der ISB oder eine andere Rolle aus der Sicherheitsorganisation muss in sicherheitsrelevanten Projekten eingebunden und informiert werden; wann, wird festgelegt.
Für eine Hochschule mit dezentraler IT liegt es nahe, je Fakultät oder Informationsverbund eine Ansprechperson für Informationssicherheit zu benennen, die mit dem ISB zusammenarbeitet und die Schnittstellen ihres Bereichs kennt. Ob die Rolle der IT-Leitung beim Rechenzentrum, bei einem CIO oder in einem Gremium liegt, regelt die Hochschule selbst; 300-1 verlangt nur, dass Rollen, Zuständigkeiten und Qualifikationen festgelegt und Konflikte vermieden werden. Für Forschungsprojekte empfiehlt sich, im Projektantrag festzulegen, wer im Projekt für Informationssicherheit zuständig ist. Diese Vorschläge sind unsere; sie stehen so nicht im Standard.
Eine Zuordnung von Entscheidungen und Nachweisen zu Rollen beschreibt die Seite Rollen und Verantwortlichkeiten. Die Leitlinie, mit der die Hochschulleitung Ziele und Organisation festlegt, behandelt die Seite Informationssicherheitsleitlinie.
Rechtlicher Rahmen: was diese Seite nicht entscheidet
Ob eine Hochschule unter das BSI-Gesetz fällt, beantwortet diese Seite nicht. Für die Einordnung kommt es unter anderem auf § 28 BSIG und die Anlagen 1 und 2 an. Anlage 2 führt im Sektor Forschung die Einrichtungsart „Forschungseinrichtungen“; § 2 Nr. 12 BSIG definiert den Begriff und nimmt Bildungseinrichtungen davon aus. Diese Begriffsbestimmung allein beantwortet nicht, ob eine Hochschule erfasst ist: Je nach Tätigkeit kommen weitere Einrichtungsarten der Anlagen 1 und 2 in Betracht, und § 28 knüpft die Einordnung außerdem an Größe und an das entgeltliche Angebot von Waren oder Dienstleistungen. Landesrechtliche Vorgaben für Hochschulen haben wir für diese Seite nicht ausgewertet.
Wir ordnen die Vorgaben ein, die Sie nennen oder die in Ihren Unterlagen stehen; ob sie rechtlich gelten, prüft Ihre Rechtsabteilung. Ein Ergebnis dieser Prüfung gehört als gesetzliche Verpflichtung in das Compliance-Management nach 300-1 Kapitel 2.2.
Wie Grundschutz++ zu den Risikomanagementmaßnahmen nach § 30 BSIG passt, beschreibt die Seite NIS2 und Grundschutz. Zur NIS2-Umsetzung informiert Blackfort Technology auf der Firmenseite: https://www.blackfort-tec.de/consulting-pages/nis2-umsetzung.
Vorgehen für eine Hochschule
Die Schritte folgen den Prozessschritten aus 300-1; die Reihenfolge und die Verbindung zur Abgrenzungsmatrix sind unser Vorschlag.
- Bestand erheben: Wer betreibt an der Hochschule welche IT? Zentrale IT, Verwaltung, Fakultäten, Forschungsgruppen und externe Dienste in die Abgrenzungsmatrix eintragen.
- Anwendungsbereich festlegen: Die Hochschulleitung entscheidet, ob der Anwendungsbereich die ganze Hochschule oder zunächst einen Teil umfasst, und benennt ausgeschlossene Bereiche (300-1 Kap. 2.3, 2.10).
- Ersten Geschäftsprozess wählen: 300-1 empfiehlt den wichtigsten Prozess aus der höchsten Schutzbedarfskategorie (Kap. 2.6). Die Prozessliste des Hochschulprofils hilft beim Einstieg.
- Informationsverbünde schneiden: Je Bereich die Option aus der Matrix festhalten, Schnittstellen zwischen den Verbünden und nach außen dokumentieren (Kap. 3.1).
- Rollen benennen: ISB, IT-Leitung, Ansprechpersonen je Fakultät oder Verbund, Zuständigkeiten in Forschungsprojekten (Kap. 2.8).
- Anforderungspaket bilden: Assets den Zielobjektkategorien zuordnen, Forschungsgeräte mit unzureichender Abdeckung kennzeichnen und ergänzen, vertragliche Verpflichtungen aufnehmen (Kap. 2.2, 3.4.2, 3.4.3).
Die Schritte im Einzelnen beschreiben die Seiten Strukturanalyse, Schutzbedarfsfeststellung und Modellierung mit Zielobjektkategorien. Blackfort Technology unterstützt Hochschulen bei der Abgrenzung von Anwendungsbereich und Informationsverbünden, der Rollenklärung und dem Aufbau des Anforderungspakets; die Pakete stehen auf der Seite Beratung. Zum allgemeinen Aufbau eines ISMS informiert die Firmenseite unter https://www.blackfort-tec.de/consulting-pages/isms-beratung, zum externen Informationssicherheitsbeauftragten unter https://www.blackfort-tec.de/consulting-pages/externer-informationssicherheitsbeauftragter.
Rechtehinweis: Zitate aus BSI-Standard 300-1 © Bundesamt für Sicherheit in der Informationstechnik 2026, Quelle: BSI-Themenseite Grundschutz++. Zitat von der BSI-Seite IT-Grundschutz-Profile © Bundesamt für Sicherheit in der Informationstechnik, Quelle: BSI-Seite IT-Grundschutz-Profile, abgerufen am 01.11.2026. Diese Zitate stehen nicht unter CC BY-SA 4.0. Zitate und Angaben aus dem IT-Grundschutz-Profil für Hochschulen, Version 2022.0.0: Urheberrecht laut Profil bei den Teilnehmerinnen und Teilnehmern der Workshop-Reihe „IT-Grundschutz-Profil für Hochschulen“, Herausgeber Arbeitskreis Informationssicherheit im ZKI e. V., lizenziert unter CC BY-SA 4.0, Quelle: BSI-Seite Profil für Hochschulen; die Zitate sind unverändert, die Zusammenfassungen unsere eigenen. Der Lizenzhinweis am Seitenende betrifft die Auszüge aus den Katalogdaten.