On-Premise bezeichnet ein Betriebsmodell, bei dem Software auf eigener Infrastruktur und in eigener Verantwortung betrieben wird, statt als Dienst beim Anbieter. Die Organisation kontrolliert Speicherort, Zugriff und Betrieb, trägt dafür aber auch Installation, Wartung, Aktualisierung und Verfügbarkeit selbst. On-Premise ist das Gegenmodell zu Software as a Service und wird häufig aus Datenschutz-, Geheimschutz- oder Verfügbarkeitsgründen gewählt.

Was bedeutet On-Premise?

On-Premise beschreibt, wo und durch wen eine Software betrieben wird – nicht, was sie leistet. Die Anwendung läuft auf Servern, über die die nutzende Organisation verfügt, in Räumen oder Rechenzentren, für die sie verantwortlich ist. Sie erwirbt oder lizenziert die Software, installiert sie, konfiguriert sie, hält sie aktuell und verantwortet Verfügbarkeit, Sicherung und Wiederherstellung.

Sprachlich korrekt ist die Form On-Premises, abgeleitet vom englischen premises für Betriebsgelände oder Räumlichkeiten. Die im deutschsprachigen Raum verbreitete Kurzform „On-Premise“ ist eine Rückbildung, die sich in Ausschreibungen, Produktbeschreibungen und im Sprachgebrauch durchgesetzt hat. Beide Schreibweisen meinen dasselbe.

Wichtig ist die Abgrenzung zum Missverständnis, On-Premise sei gleichbedeutend mit „im eigenen Keller“. Entscheidend ist nicht der geografische Standort der Hardware, sondern die Verfügungsgewalt: Wer bestimmt über die Systeme, wer hat administrativen Zugriff, und wer könnte den Betrieb einstellen? Eine Installation in einem angemieteten Rechenzentrum kann On-Premise-Charakter haben, während eine dedizierte Instanz beim Anbieter trotz eigener Umgebung ein Dienstverhältnis bleibt.

Wie unterscheidet sich On-Premise von Cloud und SaaS?

Der Unterschied zwischen den Betriebsmodellen liegt darin, wie Verantwortung zwischen Anbieter und Anwender aufgeteilt ist.

Modell	Betrieb durch	Verantwortung des Anwenders	Typische Merkmale
On-Premise	Anwender	Hardware, Betriebssystem, Anwendung, Sicherung, Aktualisierung	Volle Kontrolle, volle Betriebslast
Colocation	Anwender, Fläche vom Dienstleister	Wie On-Premise, ohne Gebäude und Stromversorgung	Eigene Hardware in fremdem Rechenzentrum
Private Cloud	Anwender oder Dienstleister	Je nach Ausgestaltung; Infrastruktur dediziert	Keine geteilte Infrastruktur mit Dritten
Infrastruktur als Dienst	Anbieter stellt Rechenleistung	Betriebssystem und Anwendung	Skalierbar, Anwender bleibt für Software zuständig
Software als Dienst (SaaS)	Anbieter	Konfiguration, Benutzerverwaltung, Daten	Geringste Betriebslast, geringste Kontrolle
Hybrid	Gemischt	Je Komponente unterschiedlich	Kritische Teile lokal, übrige als Dienst

Aus datenschutzrechtlicher Sicht ergibt sich daraus eine klare Linie: Beim Betrieb als Dienst ist regelmäßig ein Auftragsverarbeitungsvertrag erforderlich, weil der Anbieter personenbezogene Daten im Auftrag verarbeitet. Beim echten Eigenbetrieb entfällt diese Konstellation für den Regelbetrieb – sie kann aber über Fernwartung, Support oder Managed Services wieder entstehen, sobald Dritte Zugriff auf Produktivsysteme erhalten.

Welche Varianten von On-Premise gibt es?

On-Premise ist kein einheitliches Modell, sondern ein Spektrum mit unterschiedlichem Grad an Eigenverantwortung:

Klassischer Eigenbetrieb: eigene Hardware, eigene Räume, eigenes Personal – die vollständige Variante
Colocation: eigene Hardware in einem fremden Rechenzentrum, das Fläche, Strom, Kühlung und physische Sicherheit stellt
Virtualisierter Eigenbetrieb: Anwendung läuft auf eigener Virtualisierungs- oder Container-Plattform, was Bereitstellung und Aktualisierung erheblich vereinfacht
Betrieb in abgeschotteten Netzen: Installation ohne Anbindung an das Internet, etwa in Leitstellen, Produktionsnetzen oder Netzen mit besonderen Geheimschutzanforderungen
Managed On-Premise: Der Hersteller betreibt oder unterstützt die Anwendung auf der Infrastruktur des Kunden – Kontrolle über Ort und Daten bleibt, Betriebslast wird geteilt

Die letzte Variante hat in den vergangenen Jahren an Bedeutung gewonnen, weil sie den Hauptnachteil des Eigenbetriebs adressiert. Sie verlangt allerdings eine sorgfältige vertragliche Regelung, weil der Hersteller dabei administrativen Zugriff erhält und damit datenschutzrechtlich wieder in die Rolle eines Auftragsverarbeiters rücken kann.

Welche Vorteile bietet On-Premise?

Der Hauptvorteil von On-Premise ist Kontrolle – über Speicherort, Zugriff, Zeitpunkt von Änderungen und die Frage, wovon der Betrieb abhängt.

Datenhoheit. Die Daten verlassen die eigene Infrastruktur nicht. Fragen nach Drittlandübermittlung, Unterauftragsverarbeitern und extraterritorialen Zugriffsbefugnissen stellen sich für den Regelbetrieb nicht. Auch Metadaten – wer wann mit wem kommuniziert hat – verbleiben im eigenen Verantwortungsbereich, was bei Diensten Dritter regelmäßig nicht der Fall ist.

Unabhängigkeit vom Anbieter. Der Betrieb hängt nicht daran, ob ein Anbieter verfügbar ist, seine Bedingungen ändert, den Dienst einstellt oder Preise anpasst. Für Organisationen mit sehr langen Nutzungszyklen ist das ein erheblicher Planungsvorteil.

Betrieb ohne Internetanbindung. Anwendungen lassen sich in Netzen betreiben, die aus Sicherheitsgründen keine Verbindung nach außen haben. Für Leitstellen, Produktionsumgebungen und Bereiche mit Geheimschutzanforderungen ist das oft die einzig zulässige Variante.

Anpassbarkeit und Integration. Eigene Schnittstellen, angepasste Konfigurationen und die enge Verzahnung mit bestehenden Fachverfahren, Verzeichnisdiensten und Netzstrukturen sind einfacher umzusetzen als bei standardisierten Diensten.

Verfügbarkeit nach eigenen Prioritäten. Wartungsfenster, Aktualisierungszeitpunkte und Wiederanlaufreihenfolgen bestimmt die Organisation selbst – relevant überall dort, wo ein Update zur Unzeit betriebliche Folgen hätte.

Welche Nachteile und Kosten bringt On-Premise mit sich?

Der Preis der Kontrolle ist die vollständige Betriebsverantwortung. Alles, was ein Anbieter im Dienstmodell übernimmt, muss die Organisation selbst leisten:

Beschaffung und Lebenszyklus von Servern, Speicher, Netzwerk und Lizenzen samt Ersatzbeschaffung nach einigen Jahren
Betrieb rund um die Uhr: Überwachung, Störungsbehebung, Rufbereitschaft, Kapazitätsplanung
Aktualisierung und Härtung: zeitnahes Einspielen von Sicherheitsupdates, Konfigurationspflege, Schwachstellenmanagement
Sicherung und Wiederherstellung einschließlich getrennter, unveränderlicher Sicherungen und geübter Rückspielungen
Hochverfügbarkeit und Notfallbetrieb, sofern die Anwendung kritisch ist – mit entsprechender Redundanz
Personal und Kompetenz, dauerhaft und vertretungssicher, nicht nur für die Einführungsphase
Infrastrukturkosten für Fläche, Strom, Kühlung, Brandschutz und physische Sicherheit

Bei der Wirtschaftlichkeitsbetrachtung ist der häufigste Fehler, Anschaffungskosten mit Abonnementkosten zu vergleichen. Aussagekräftig ist nur eine Gesamtkostenrechnung über die geplante Nutzungsdauer, die Personal, Ersatzbeschaffung, Wartungsverträge und Ausfallrisiken einbezieht. Je nach Organisation fällt das Ergebnis unterschiedlich aus: Wo Rechenzentrum und Betriebspersonal ohnehin vorhanden sind, verschiebt sich die Rechnung deutlich zugunsten des Eigenbetriebs; wo beides erst aufgebaut werden müsste, selten.

Ist On-Premise sicherer als die Cloud?

Nicht automatisch. On-Premise verlagert die Verantwortung für Sicherheit, es erhöht sie nicht von selbst – und diese Unterscheidung ist die wichtigste bei der Modellwahl.

Im Dienstmodell übernimmt der Anbieter einen erheblichen Teil der Absicherung: Patchen der Plattform, Härtung, Überwachung, Redundanz, physische Sicherheit. Große Anbieter betreiben dafür spezialisierte Teams, die einzelne Organisationen selten vorhalten können. Beim Eigenbetrieb fällt all das an die eigene IT zurück. Eine On-Premise-Installation, die über Monate nicht aktualisiert wird, deren Protokolle niemand auswertet und deren Sicherungen nie zurückgespielt wurden, ist unsicherer als ein sorgfältig betriebener Dienst – und genau solche Installationen sind ein bevorzugtes Ziel für Ransomware, weil sie oft aus dem Internet erreichbar und selten gepflegt sind.

Umgekehrt bietet der Eigenbetrieb Schutzmöglichkeiten, die im Dienstmodell nicht existieren: Betrieb ohne Internetanbindung, vollständige Netzsegmentierung, keine Abhängigkeit von der Sicherheitslage eines Anbieters, kein Zugriff Dritter auf Inhalte und Metadaten. Für bestimmte Schutzbedarfe sind diese Eigenschaften nicht ersetzbar.

Die belastbare Frage lautet deshalb nicht „Cloud oder On-Premise“, sondern: Wer kann das jeweilige Modell tatsächlich sicher betreiben, und über welchen Zeitraum? Dieselbe Kompetenzfrage entscheidet auch über digitale Souveränität – ein Eigenbetrieb ohne die Fähigkeit, ihn zu bewerten und zu pflegen, schafft Abhängigkeit von Dienstleistern statt Unabhängigkeit.

Welche regulatorischen Gründe sprechen für On-Premise?

Regulatorisch ist On-Premise selten vorgeschrieben, aber häufig der einfachste Weg, Anforderungen zu erfüllen.

Datenschutzrechtlich entfällt beim Eigenbetrieb die Drittlandproblematik, und die Nachweisführung zur DSGVO-Konformität vereinfacht sich, weil weder Auftragsverarbeitung noch eine Kette von Unterauftragsverarbeitern zu dokumentieren ist. Bei Berufsgeheimnisträgern – etwa in Kliniken, Kanzleien und Praxen – reduziert der Eigenbetrieb zusätzlich die strafrechtlich relevante Frage, welche externen Personen Zugriff auf geschützte Informationen erhalten.

Im Bereich des Geheimschutzes ist der Eigenbetrieb für als Verschlusssache eingestufte Inhalte häufig zwingend, verbunden mit besonderen Anforderungen an Zulassung, Netztrennung und Betriebsumgebung. Für Betreiber kritischer Infrastrukturen und Einrichtungen im Anwendungsbereich von NIS-2 ist On-Premise dagegen keine Pflicht – dort geht es um Risikomanagement und Lieferkettensicherheit, die sich in beiden Modellen erfüllen lassen. Der Eigenbetrieb verkürzt allerdings die Lieferkette und damit den Prüf- und Nachweisaufwand erheblich.

Was bedeutet On-Premise für Kommunikationslösungen?

Bei Kommunikationslösungen ist der Eigenbetrieb besonders häufig gefragt, weil Nachrichteninhalte und Verbindungsdaten zu den sensibelsten Beständen einer Organisation gehören. Praktisch stellen sich dabei vier Fragen, die vor der Einführung geklärt sein sollten.

Anbindung an den Verzeichnisdienst: Nutzerkonten, Gruppen und Berechtigungen sollten aus dem bestehenden Verzeichnis stammen, damit Ein- und Austritte automatisch wirken und Identitäten nicht doppelt gepflegt werden. Betrieb ohne Internetanbindung: Ob eine Lösung in einem abgeschotteten Netz vollständig funktioniert, ist eine Architekturfrage und keine Konfigurationsoption – sie muss vorab geprüft werden.

Push-Benachrichtigungen auf Mobilgeräten sind der am häufigsten übersehene Punkt. Mobile Betriebssysteme stellen Benachrichtigungen üblicherweise über die Dienste der Plattformanbieter zu; ein rein lokal betriebener Server erreicht ein Gerät im Ruhezustand daher nicht ohne Weiteres. Je nach Lösung existieren unterschiedliche Ansätze, von einer eng begrenzten Weiterleitung ohne Inhalte bis zu abfragebasierten Verfahren mit entsprechenden Auswirkungen auf Akkulaufzeit und Zustellzeit. Wer Alarmierung über Mobilgeräte plant, sollte diesen Punkt früh und konkret klären.

Verteilung und Verwaltung der Clients schließlich erfolgt über die Geräteverwaltung – einschließlich Konfiguration, Zertifikaten und Richtlinien, damit die Anwendung ohne Nutzereingriff nutzbar ist. Für BOS und Organisationen mit ehrenamtlichen Kräften kommt die Frage hinzu, wie private Geräte eingebunden werden, ohne Dienstliches und Privates zu vermischen.

Wann ist On-Premise die richtige Wahl?

On-Premise ist die richtige Wahl, wenn mindestens eine der folgenden Bedingungen zutrifft und die Betriebsfähigkeit gesichert ist:

Es werden eingestufte oder besonders schutzbedürftige Informationen verarbeitet, für die externe Verarbeitung ausgeschlossen ist
Der Betrieb muss ohne Internetanbindung oder in vollständig getrennten Netzen möglich sein
Rechenzentrum, Betriebspersonal und Prozesse sind vorhanden und die Anwendung fügt sich ohne Aufbau neuer Strukturen ein
Es bestehen vertragliche oder aufsichtliche Vorgaben, die den Eigenbetrieb verlangen
Die geplante Nutzungsdauer ist lang und die Anforderungen sind stabil

Gegen den Eigenbetrieb spricht dagegen, wenn kein dauerhaftes Betriebsteam zur Verfügung steht, wenn Patch- und Sicherungsdisziplin nicht verlässlich gewährleistet sind, wenn Nutzerzahlen stark schwanken oder wenn schnelle Einführung wichtiger ist als maximale Kontrolle. In der Praxis entscheiden sich viele Organisationen für ein hybrides Modell, bei dem besonders schutzbedürftige Bereiche lokal betrieben und weniger kritische Anwendungen als Dienst bezogen werden.

Eine belastbare Entscheidung setzt in jedem Fall eine ehrliche Bestandsaufnahme voraus: Welche Kompetenzen sind vorhanden, welche müssten aufgebaut werden, und wer betreibt das System in fünf Jahren?

Zusammenfassung: Wichtige Punkte zu On-Premise

On-Premise bezeichnet den Betrieb von Software auf eigener Infrastruktur und in eigener Verantwortung statt als Dienst beim Anbieter.
Sprachlich korrekt ist On-Premises; die verkürzte Form hat sich im deutschen Sprachgebrauch dennoch durchgesetzt.
Entscheidend ist nicht der Standort der Hardware, sondern die Verfügungsgewalt über die Systeme.
Das Modell reicht vom klassischen Eigenbetrieb über Colocation und abgeschottete Netze bis zu Managed On-Premise.
Vorteile sind Datenhoheit, Anbieterunabhängigkeit, Betrieb ohne Internetanbindung und Anpassbarkeit.
Der Preis ist die vollständige Betriebsverantwortung – von Beschaffung über Aktualisierung bis zu Notfallbetrieb und Personal.
On-Premise ist nicht automatisch sicherer: Eine ungepflegte lokale Installation ist unsicherer als ein sorgfältig betriebener Dienst.
Regulatorisch ist der Eigenbetrieb selten vorgeschrieben, verkürzt aber die Lieferkette und damit den Prüf- und Nachweisaufwand.
Bei Kommunikationslösungen sind Verzeichnisanbindung, Betrieb ohne Internet, Push-Benachrichtigungen und Geräteverwaltung vorab zu klären.
Die Entscheidung sollte an der tatsächlichen Betriebsfähigkeit ausgerichtet werden, nicht allein am Wunsch nach Kontrolle.