IT-Regelungen 2.0

Informationssicherheitsordnung und Richtlinie zur Nutzung digitaler Dienste
Workshop am 28. September 2026 mit ZID, ZDL, CISO, Recht

Andy Weeger (CIO)

Neu-Ulm University of Applied Sciences

28. September 2026

Agenda

Ablauf

1. Agenda und Zielstellung
2. Ausgangslage
3. Zielarchitektur
4. Rollen
5. Beispielfälle
6. Feedback
7. Grundsatzfragen
8. Ausblick

Ziele und Nicht-Ziele

Ziele

• Gemeinsames Verständnis zu Notwendigkeit & Architektur schaffen
• Einschätzungen zum Gesamtbild einsammeln
• Vier Grundsatzfragen diskutieren und entscheiden

Nicht-Ziele

• Die 73 Kommentare durchgehen
• Formulierungen im Detail abstimmen
• Punkte klären, die anderswo entschieden werden

Von den 73 Rückmeldungen sind

• 30 eingearbeitet
• 13 redaktionell übernommen
• 18 können bilateral diskutiert werden und
• 5 liegen müssen außerhalb dieser Runde diskutiert werden.

7 grundsätzliche Rückmeldungen diskutieren wir heute.

Zusage: kein Kommentar geht verloren, die Übersicht kommt im Nachgang.

Ausgangslage

Sechs Probleme am Status Quo

• SaaS, in dem Daten verarbeitet werden, ist nirgends geregelt.
  Die Cloud-Richtlinie von 2019 regelt nur Speicherdienste.
• Für Forschung und Lehre gibt es keine (praktikablen) Regeln.  Werkzeuge ohne Auftragsverarbeitungsvertrag sind faktisch verboten und werden trotzdem gebraucht. Das Ergebnis ist Schatten-IT, nicht Regeltreue.
• Datenklassen sind nicht definiert.
  Ohne Klassifikation lassen sich keine vernünften Regeln formulieren.
• Rollen sind nicht definiert.
  Wer prüft, wer entscheidet, wer verantwortet: nirgends festgelegt. Dokumente sind inkonsistent.
• Die KI-Regeln binden niemanden.
  Handlungsempfehlungen sind keine Rechtsgrundlage.
• Die Rechtsgrundlagen sind überholt.
  Das BayHIG ist nicht adressiert, ebenso Art. 43 Abs. 1 BayDiG (Informationssicherheitskonzept) und weitere.

Die ersten beiden sind die eigentlichen Treiber. Der Rest folgt daraus.

Zielarchitektur

Konsolidierung und Erweiterung der Regelungen

Status Quo

• DV-Benutzerordnung 2016
• Cloud-Richtlinie 2019
• Handlungsempfehlungen KI
• verstreute Einzelregelungen

Künftig

Informationssicherheitsordnung

Satzung, beschlossen vom Senat. Zugleich DV-Benutzerordnung und Informationssicherheitsleitlinie nach Art. 43 Abs. 1 BayDiG.

Richtlinie zur Nutzung digitaler Dienste

Erlassen von der Hochschulleitung auf Grundlage der Satzung und damit fortschreibbar, ohne den Senat.

KI ist kein eigener Regelungsgegenstand, sondern ein Merkmal digitaler Dienste. Deshalb braucht es keine KI-Richtlinie neben einer Cloud-Richtlinie.

Geteilte Verantwortung, klar geregelt

Die HNU kann prüfen, ob Vertrag, Konfiguration und Grundschutz eines Dienstes tragen. Sie kann jedoch nicht garantieren, dass die Nutzung im Einzelfall rechtmäßig bleibt:
Das hängt davon ab, welche Daten Nutzende dem Dienst anvertrauen.

Die HNU prüft

• Anbieter, Vertragslage und Konfiguration
• Einstufung in einen von fünf Diensttypen
• Eintrag im Register digitaler Dienste
• Regel- und Anlassprüfung über den Lebenszyklus

Nutzende binden sich an klare Regeln

• Toolagnostisch, gelten für jeden Dienst
• Abgeleitet aus Datenklasse mal Diensttyp
• Gelten auch für ungeprüfte Dienste
• Erläutert in einem One-Pager für den Alltag

Beide Seiten sind in den Dokumenten klar und verbindlich geregelt.

Diensttypen

Typ 1: Eigenbetrieb

Betrieb durch die HNU oder in ihrem Auftrag auf eigener Infrastruktur.

Typ 2: Wissenschaftsverbund

Öffentliche Wissenschaftseinrichtung auf Grundlage einer Verbundvereinbarung.

Typ 3: Auftragsverarbeitung EU

Externer Anbieter, AVV liegt vor, Verarbeitung in der EU.

Typ 4: Auftragsverarbeitung Drittland

AVV liegt vor, Verarbeitung ganz oder teilweise im Drittland.

Typ 5: ohne Auftragsverarbeitung

Kein AVV, weil der Anbieter keine personenbezogenen Daten im Auftrag der HNU verarbeitet. Konsequenz: Nutzung sofort möglich aber nur mit öffentlichen Daten.

Ein Auftragsverarbeitungsvertrag ist nur erforderlich, wenn der Anbieter personenbezogene Daten im Auftrag der HNU verarbeitet. Werden ausschließlich öffentliche, anonyme oder rein sachliche Daten eingegeben, liegt keine Auftragsverarbeitung vor. Hinsichtlich der Zugangs- und Nutzungsdaten der handelnden Person ist der Anbieter eigenständig Verantwortlicher. Typ 5 schafft die Möglichkeit, dass Forschung und Lehre Werkzeuge nutzen können, die sich nicht vollständig prüfen lassen. Jedoch nur mit öffentlichen Daten, dafür sofort.

Regelmatrix

Datenklasse	Typ 1	Typ 2	Typ 3	Typ 4	Typ 5
D1 Öffentlich	ja	ja	ja	ja	ja
D2 Intern	ja	ja	ja	ja	nein
D3 Vertraulich	ja	ja	bedingt	bedingt	nein
D4 Streng vertraulich	ja	nein	nein	nein	nein

Tabelle 1: Zulässige Datenklassen je Diensttyp,

Der Registereintrag kann engere Vorgaben treffen, weitergehende nicht.

Das Register

Insgesamt zehn Felder je Dienst, für alle im Intranet sichtbar, gepflegt durch das ZID.

Bezeichnung und Anbieter

wer betreibt den Dienst

Diensttyp

1 bis 5 nach § 5 Abs. 3

Verarbeitungsort

inklusive Unterauftragsverarbeiter

Zulässige Datenklassen

D1 bis D4

KI-Funktionen

ja oder nein

Bereitstellungsweg

zentral verteilt, selbst installierbar oder ohne lokale Komponente

Auflagen

Konfiguration, Einschränkungen

Datenschutzinformationen

Art. 13 und 14 DSGVO

Service Owner und Systemverantwortung

entfällt bei Typ 5

Letzte Prüfung und nächster Termin

entfällt bei Typ 5

Konsolidierungseffekt

Keine zusätzliche Bürokratie: Wir pflegen fast ausschließlich Daten, die wir auch so vorhalten müssen. Bünden diese an einer Stelle mit klarer Zuständigkeit.

• Art. 43 Abs. 1 BayDiG. Ein Informationssicherheitskonzept mit angemessenen Maßnahmen setzt voraus, dass wir wissen, welche Dienste im Einsatz sind. Man kann nicht schützen, was man nicht kennt.
• Art. 30 DSGVO. Das Verzeichnis von Verarbeitungstätigkeiten ist ohnehin Pflicht. Ohne Register wird es aus dem Gedächtnis gepflegt.
• BSI IT-Grundschutz. Strukturanalyse und Schutzbedarfsfeststellung setzen eine Übersicht der Anwendungen voraus. Ohne Assetliste kein ISMS.
• Art. 43 Abs. 3 BayDiG. Die Unterrichtungspflicht gegenüber dem LSI lässt sich nur erfüllen, wenn wir binnen Stunden sagen können, ob wir betroffen sind.
• Art. 26 KI-VO. Betreiberpflichten setzen voraus, dass bekannt ist, welche KI-Systeme laufen, auch die, die als Funktion in bestehenden Diensten auftauchen.
• EN 301 549. Für die Erklärung der Barrierefreiheit muss ich die Angebote kennen.

Nutzen des Registers

Das leistet das Register

• Auskunft an Nutzende: was darf ich benutzen, mit welchen Daten, unter welchen Auflagen
• Doppelbeschaffung erkennen, bevor der dritte Vertrag geschlossen wird
• Wer ist Service Owner, wer Systemverantwortung: an einer Stelle statt in Köpfen
• Welche Dienste haben KI-Funktionen: Grundlage für die Betreiberpflichten
• Prüfstände und Termine, damit nichts unbemerkt veraltet

Das leistet es nicht

• Wer einen Dienst nutzt. Das Register kennt den Service Owner, nicht die Nutzenden; die muss der Service Owner selbst führen
• Kosten, Verträge, Lizenzen und Kündigungsfristen.
• (Verantwortung für Typ-5-Dienste im Sinne eines Service Ownders)

Rollen

Operative Rollen

Nutzende

zeigen Typ-5-Dienste an, begrenzen den Zugriffsbereich von KI-Agenten, melden erkennbare Änderungen, kennzeichnen KI-Ergebnisse

Service Owner

beantragt Freigabe, Zweck und Datenklassen, verantwortet die fachlichen Angaben und die datenschutzrechtliche Bewertung, unterrichtet Nutzende; bei Typ 5 nicht benannt

IT-Systemverantwortung

technisch verantwortlich, steuert den Dienstleister, pflegt den Registereintrag, empfängt Anbieteranzeigen; bei Typ 5 nicht benannt

ZID

führt das Register, koordiniert Freigabe- und Regelprüfung, trägt Typ-5-Dienste ein, kann bei Gefahr herabstufen oder technisch sperren

ISB

prüft Dienste vor der Freigabe und anlassbezogen, nimmt bei Einzelfreigaben in der Forschung die Kurzprüfung vor

DSB

berät und überwacht, entscheidet nicht und gibt nicht frei; zwingend zu beteiligen bei Art. 9 DSGVO, Drittland, DSFA-Pflicht oder D3/D4

Gremien

Justiziariat

ordnet ein, ob die HNU nach der KI-Verordnung als Anbieter oder als Betreiber handelt

CIO und CISO

bereiten die Freigabeentscheidungen vor und legen sie im Einvernehmen vor; ohne Einvernehmen entscheidet die Hochschulleitung

Hochschulleitung

entscheidet über Freigaben, Höherstufungen, Datenklassen, Negativliste, Einzelfreigaben in der Forschung und Hochrisiko-KI

eHL

berät die Hochschulleitung vor der Freigabeentscheidung (Art. 34 Abs. 3 Nr. 1 BayHIG)

Personalrat

Mitbestimmung nach Art. 75a Abs. 1 Nr. 1 BayPVG, Beteiligung bereits in der Planungsphase, Freigabe erst nach deren Abschluss

ZDL

stellt Handreichungen zu didaktischen und prüfungsrechtlichen Fragen bereit

Ohne die Hochschulleitung darf nur gehandelt werden, wenn Risiko gesenkt wird. Herabstufen und Sperren dürfen ZID und CISO sofort, höherstufen und freigeben nicht.

Offen und auf dem Parkplatz: ISB oder IT-Sicherheitsbeauftragter, und was gilt, wenn Betriebsbelange des ZID und Sicherheitsanforderungen kollidieren.

Beispiel-Fälle

Der CIO Claude Code einsetzen

1. Steht der Dienst im Register? (Register)
   Nein. Damit gilt er nach § 5 Abs. 4 wie Typ 5: zulässig sind ausschließlich Daten der Klasse Öffentlich (D1).
2. Ist die Nutzung anzuzeigen? (Nutzende)
   Ja, sobald eines der drei Merkmale vorliegt: HNU-Kennung, Beschaffung aus HNU-Mitteln, Einbeziehung Dritter.
3. Anzeige beim ZID vor der ersten Nutzung. (ZID)
   Das ZID trägt den Dienst als Typ 5 ein und stößt die Prüfung an. Die Anzeige hemmt die Nutzung nicht.
4. Arbeiten unter den Regeln des § 8. (Nutzende)
   Der Zugriffsbereich des Agenten gilt als Eingabe (also bspw. kein Zugriff auf Postfächer, Fachverfahren oder Ablagen mit Daten des Typs D4. Optional Software mit lokalen Admin-Rechten selbst installieren, bis über die Software-Verteilung verfügbar.
5. Später: Entscheidung über den Typ. (Hochschulleitung)
   Die Hochschulleitung entscheidet über die Typzuordnung. Höherstufung auf Typ 3 oder 4 ist möglich+. Nutzen mehrere Personen den Dienst, wird er über die Softwareverteilung bereitgestellt.

Die Nutzung beginnt sofort, jedoch nur mit öffentliche Daten und (vorerst) nur über den Browser.

SuP will einen Chatbot auf hnu.de einführen

1. Service Owner benennen. (Fachbereich)
   Ohne benannten und zustimmenden Service Owner läuft das Verfahren nicht an.
2. Antrag oder Beschaffungsantrag. (Service Owner)
   Die SO stößt die Prüfung an. Art und Tiefe richten sich nach den beantragten Datenklassen und dem Betriebsmodell.
3. Prüfung und datenschutzrechtliche Bewertung. (ZID, ISB, DSB)
   ZID und ISB prüfen. Die Bewertung verantwortet der Service Owner, das ZID unterstützt. Die DSB wird beteiligt, sobald eine der Schwellen des § 5 Abs. 2 greift.
4. Einordnung nach der KI-Verordnung. (SO und Justiziariat)
   Wenn die HNU Betreiber ist, folgt die Transparenzpflicht: Die Interaktion muss als KI erkennbar sein.
5. Mitbestimmung prüfen. (Personalrat)
   Greift Art. 75a Abs. 1 Nr. 1 BayPVG, wird der Personalrat schon in der Planungsphase beteiligt. Die Bearbeitungsfrist ruht so lange.
6. Vorlage, Beratung, Freigabe. (Hochschulleitung)
   CIO und CISO legen im Einvernehmen vor, die eHL berät, die HL entscheidet. Danach Registereintrag und Prüfung vor Produktivbetrieb.

Feedback

Was sind Ihre größten Bedenken?

Zweieinhalb Minuten pro Einheit: ZID, ZDL, CISO, Recht.

02:30

Einsortieren:

C1

gehört in die vier Grundsatzfragen

C2

klären wir zu zweit, im Folgetermin

D

liegt außerhalb dieses Kreises

Grundsatzfragen

#1 Dokument-Architektur

Angelegte Architektur:

• Die Ordnung als Satzung durch den Senat verabschiedet
• Die Richtlinie darauf gestützt durch die Hochschulleitung verabschiedet (für Beschäftigte zugleich Dienstanweisung)
• Geteilte Verantwortung als Grundprinzip und KI als Merkmal digitaler Dienste (kein eigener Regelungsgegenstand)

Diskussion

Gibt es Einwände zur Architektur und/oder Alternativvorschläge?

#2 Betriebsmodell

Organisatorische Grundvoraussetzungen

1. Benennung eines Service Owners durch die Fachbereiche
2. Registerführung durch das ZID
3. Prozess zur Prüfung neuer Dienste (innerhalb der Frist)

Vorschlag

Unter folgenden Bedingungen umsetzbar:

• Falls sich kein Service Owner findet, entscheidet die HL auf Vorschlag des CIO
• Es gibt eine Bearbeitungsfrist zur Prüfung von 8 Wochen (Spielraum und Verbindlichkeit)
• Wir richten eine Übergangszeit zur Erstellung der Basisversion des Registers ein (12 Monate)

#3 Datenklassen

Das ganze Regelwerk hängt daran, dass Nutzende ihre Daten einer von vier Klassen zuordnen können. Ich halte das für möglich und sinnvoll. Der CISO hält die Selbsteinstufung für fehleranfällig und die Grenze zwischen D3 und D4 für unscharf.

Optionen

1. Das Modell bleibt. Anhang A bekommt Regelbeispiele aus dem Hochschulalltag und eine benannte Eskalationsstelle für Zweifelsfälle
2. Neukonzeption auf Basis eines konstruktiven Vorschlags aus der Runde (Schärfung und Einstufungsmechanismus)

#2 Typ 5 (Ausnahmemodell)

• § 5 Abs. 4 nennt Typ 5 ausdrücklich ein Ausnahmemodell und keine Standardfreigabe für den regulären Einsatz.
• § 13 Abs. 2 erlaubt die Nutzung bis zu einer Entscheidung, die ggf. niemanden trifft, wenn die Prüfung liegen bleibt (also unbefristet).
• § 5a Abs. 3 beauftragt das ZID, anlassbezogen Warnungen von BSI, LSI und Aufsichtsbehörden gegen das Register auszuwerten.
• Offen ist die Frist bis zur Entscheidung.

Optionen

1. Die Anzeige gilt unbefristet. Die Prüfung nach § 5 Abs. 1 läuft an; bleibt sie liegen, ändert sich nichts (kein Verwaltungsaufwand, aber Ausnahme wird zum Dauerzustand)
2. Ist die Prüfung nach zwölf Monaten nicht abgeschlossen, gilt der Eintrag als „Prüfung überfällig”. Die bestehende Nutzung läuft weiter, darf aber nicht auf weitere Personen oder Zwecke ausgeweitet werden (zusätzlicher Aufwand: Fristen im Register führen und überwachen; gilt auch für Typen 1-4).

Weitere offene Punkte

Bilateral und Ergebnisse per Mail

• CISO (12): Incident-Response-Führung, Protokoll-Löschfristen, Verschlüsselungsklausel, Dauer von Einzelfreigaben, etc.
• ZID (4): Klassifikation durch die fachlich verantwortliche Stelle, Kennzeichnung der Datenklassen, Registerinhalte.
• Recht (2): Geltungsbereich, Kennzeichnung über Art. 50 KI-VO hinaus.

Außerhalb dieses Kreises zu klären

• AGO § 10 Abs. 4 und § 6a: Recht, ggf. Anfrage StMWK
• Satzungsrang und Senatsweg: Recht und Kanzler
• DV IuK und Personalrat: Kanzler/CIO
• Beschaffung und EVB-IT: ZID und Finanzen
• Zuständigkeit Barrierefreiheit: Kanzler

Ausblick

Zeitpunkt	Was passiert
Diese Woche	Übersicht aller 73 Rückmeldungen mit Korbzuordnung an diese Gruppe
Bis Mitte Oktober	Bilaterale Klärung der 18 Detailpunkte
Folgetermin	Testfälle zur Klassifikation, Registergröße, Fristen (90 Minuten)
Ende Oktober	Fassung v1.0
November	Beteiligung weiterer Stakeholder: Personalrat, Dekaninnen und Dekane, Studierendenvertretung, Schwerbehindertenvertretung
Ende November	Beratung in der eHL
Dezember	Vorlage im Senat

Tabelle 2: Zeitplan bis zur Senatsvorlage

Schlussfolie

Vielen Dank

Andy Weeger
andy.weeger@hnu.de