Definition
On-Premise Software wird auf der Infrastruktur der nutzenden Organisation betrieben — im internen Rechenzentrum, auf dedizierten Servern oder auf eigenen virtuellen Maschinen. Der Unterschied zu Software as a Service liegt nicht in der Anwendung, sondern in der Frage, wer den Betrieb verantwortet und wo die Daten liegen.
Der Begriff hat sich verschoben. Vor zehn Jahren bedeutete On-Premise typischerweise einen physischen Server im Keller. Heute liegt die Anwendung meist containerbasiert auf virtualisierter Infrastruktur, die auch angemietet sein kann. Entscheidend ist nicht das Blech, sondern die Kontrolle: Wer entscheidet über Updates, wer hat administrativen Zugriff, und wer kann auf die Daten zugreifen?
Betriebsvarianten
Zwischen „alles selbst“ und „alles beim Anbieter“ liegen mehrere Zwischenformen, die in Ausschreibungen und Verträgen regelmäßig vermischt werden.
| Variante | Infrastruktur | Administrativer Zugriff | Anbieterzugriff auf Daten |
|---|---|---|---|
| Klassisch On-Premise | eigenes Rechenzentrum | eigene IT | keiner |
| On-Premise mit Fernwartung | eigenes Rechenzentrum | eigene IT, Anbieter auf Anforderung | zeitlich begrenzt, protokolliert |
| Private Cloud beim Dienstleister | dedizierte Umgebung beim Dritten | Dienstleister | ja, vertraglich geregelt |
| Managed Hosting durch den Anbieter | Anbieterumgebung, eigene Instanz | Anbieter | ja |
| Software as a Service | Anbieterumgebung, geteilt | Anbieter | ja |
Die erste und zweite Zeile sind On-Premise. Ab der dritten verarbeitet ein Dritter personenbezogene Daten im Auftrag — mit allen Folgen für Vertrag, Dokumentation und Rechenschaftspflicht.
Datenhoheit
Das stärkste Argument für On-Premise ist selten der Preis, sondern die Frage, wer Zugriff hat. Drei Punkte sind dabei konkret prüfbar.
Kein Auftragsverarbeitungsvertrag nötig. Art. 28 DSGVO greift, wenn jemand personenbezogene Daten im Auftrag verarbeitet. Beim reinen On-Premise-Betrieb ohne Anbieterzugriff entfällt das. Sobald Fernwartung oder Supportzugriff auf Produktivdaten hinzukommt, entsteht für diesen Teil wieder eine Auftragsverarbeitung — sauber ist deshalb eine Regelung, die Fernzugriff nur auf Anforderung, zeitlich begrenzt und protokolliert zulässt.
Keine Drittlandübermittlung. Art. 44 ff. DSGVO verlangen für Übermittlungen in Drittländer geeignete Garantien. Wer die Anwendung im eigenen Rechenzentrum betreibt, muss diese Prüfung für die Fachanwendung nicht führen — sie bleibt aber für alles bestehen, was die Anwendung nach außen ruft: Kartendienste, Telematikanbieter, E-Mail-Versand.
Eigene Sicherheitsmaßnahmen. Art. 32 DSGVO verlangt angemessene technische und organisatorische Maßnahmen. Bei On-Premise liegen diese überwiegend in eigener Hand — das ist Vorteil und Pflicht zugleich. Ein Server ohne Patch-Routine und ohne getestete Rücksicherung ist nicht sicherer als eine Cloud, sondern unsicherer. Welche Pflichten im Fuhrpark daraus konkret folgen — Verzeichnis der Verarbeitungstätigkeiten, Löschfristen, Auskunft —, steht unter DSGVO-Konformität.
Abgrenzung zu Private Cloud und Self-Hosting
Private Cloud ist kein Ort, sondern ein Bereitstellungsmodell: eine nur für eine Organisation betriebene Umgebung. Sie kann im eigenen Rechenzentrum stehen — dann ist sie On-Premise — oder bei einem Dienstleister, dann nicht. Die Bezeichnung allein sagt über Datenhoheit nichts aus; entscheidend ist, wer administrativen Zugriff hat.
Self-Hosting bezeichnet denselben Sachverhalt aus dem Open-Source-Blickwinkel: Man betreibt die Anwendung selbst, statt den gehosteten Dienst desselben Anbieters zu nutzen. Im Unternehmenskontext sind beide Begriffe austauschbar.
Hybride Modelle kombinieren beides: Die Fachanwendung läuft im Haus, einzelne Dienste — Kartenmaterial, Routenberechnung, Telematik — kommen von außen. Diese Modelle sind der Regelfall, nicht die Ausnahme. Wichtig ist, sie als solche zu benennen: „On-Premise“ auf dem Deckblatt und drei externe Schnittstellen im Betrieb ist eine Aussage, die in einer Datenschutzfolgenabschätzung nicht trägt.
In der Praxis
Der Betriebsaufwand im Jahreslauf. Realistisch sind zwei bis vier Updatefenster, ein Rücksicherungstest, die Erneuerung von Zertifikaten und die laufende Überwachung. Für eine Organisation, die ohnehin Server betreibt, fällt das unter bestehende Prozesse. Für eine, die keine eigene IT hat, ist es der entscheidende Kostenblock — und der Grund, warum die Entscheidung für oder gegen On-Premise nicht am Softwarepreis hängt.
Was zu klären ist, bevor entschieden wird. Gibt es eine betriebene Virtualisierungsumgebung? Wer betreibt Datenbanken, und mit welcher Sicherung? Existiert ein Patch-Prozess mit Testfenster? Gibt es ein Monitoring, das Ausfälle meldet, bevor Nutzer anrufen? Wer diese vier Fragen nicht mit Ja beantwortet, betreibt On-Premise faktisch nicht — und ist mit einer betreuten Variante besser bedient.
Was in den Vertrag gehört. Die technischen Systemanforderungen, die unterstützten Betriebssystem- und Datenbankversionen, der Umgang mit Versionswechseln, die Regeln für Fernzugriff und die Frage, wie lange eine gekaufte Version noch Sicherheitsupdates erhält. Der letzte Punkt ist bei einer Einmallizenz der wichtigste und wird am häufigsten offengelassen. Ebenfalls in den Vertrag gehört, welche Fassung der Systemanforderungen gilt: Ein Wechsel der unterstützten Datenbankversion kann eine Infrastrukturmaßnahme auslösen, die im Beschaffungsjahr niemand eingeplant hat.
Mandantenfähigkeit. Auch On-Premise-Installationen brauchen häufig eine Trennung zwischen Einheiten — Standorte, Tochtergesellschaften, angeschlossene Kommunen. Ob die Anwendung das über getrennte Instanzen oder über Mandantenfähigkeit löst, entscheidet über Betriebsaufwand und Auswertbarkeit über alle Einheiten hinweg.
Auch bekannt als: On-Prem, On-Premises, Self-Hosted, Inhouse-Betrieb, Eigenbetrieb, lokale Installation, Software im eigenen Rechenzentrum
Häufige Fragen
Die Software läuft auf Servern, die die nutzende Organisation kontrolliert — im eigenen Rechenzentrum, in einem angemieteten Rack oder auf eigenen virtuellen Maschinen. Installation, Updates, Backup und Betrieb liegen damit in ihrer Hand, ebenso der Zugriff auf die Daten. Der Gegenbegriff ist Software as a Service, bei der Betrieb und Datenhaltung beim Anbieter liegen.
On-Premise meint den Ort und die Kontrolle: eigene Infrastruktur, eigene Verantwortung. Private Cloud meint das Bereitstellungsmodell: eine ausschließlich für eine Organisation betriebene Umgebung, die durchaus bei einem Dienstleister stehen kann. Eine Private Cloud im Rechenzentrum des Anbieters ist kein On-Premise-Betrieb — die Daten liegen dort bei einem Dritten, und damit greift die Auftragsverarbeitung nach Art. 28 DSGVO.
Im Sprachgebrauch weitgehend ja, in der Betonung nicht. „Self-Hosted“ stammt aus dem Open-Source-Umfeld und betont, dass man eine Anwendung selbst betreibt, statt einen gehosteten Dienst desselben Anbieters zu nutzen. „On-Premise“ stammt aus dem Unternehmensumfeld und betont den Ort der Infrastruktur. Beide bezeichnen denselben Sachverhalt aus unterschiedlicher Richtung.
In der Regel nicht — wenn der Anbieter keinen Zugriff auf die Daten hat. Art. 28 DSGVO greift, sobald jemand personenbezogene Daten im Auftrag verarbeitet. Beim reinen On-Premise-Betrieb ohne Fernzugriff verarbeitet der Anbieter nichts. Sobald aber Fernwartung, Supportzugriff auf Produktivsysteme oder Telemetrie hinzukommen, entsteht eine Auftragsverarbeitung für diesen Teil — und dafür ist ein Vertrag nötig.
Server oder virtuelle Maschinen, Datenbank, Backup und Rücksicherungstest, Zertifikate, Monitoring und das Einspielen von Updates. Bei containerbasierter Auslieferung reduziert sich das auf wenige Stunden im Quartal, sofern die Basisinfrastruktur ohnehin betrieben wird. Der Aufwand verschwindet nicht — er wird nur von einem laufenden Preis in eine interne Leistung umgewandelt. Wer das vergleichen will, rechnet beide Seiten mit denselben Positionen.