Sie möchten in Ihrem Unternehmen eine neue Software-Lösung einführen (z.B. ein Qualitätsmanagement-System, eine Prüfmitteldatenbank oder ein Dokumentmanagement-System) und stellen sich die Frage, wie die Software bei Ihnen betrieben werden soll – und dabei läuft Ihnen auch der Begriff „Managed Service“ über den Weg?
Häufig gibt es in der Kommunikation mit dem Compliance- und IT-Verantwortlichen die folgende wichtige Differenzierung:
- Software im „on-premises-Betrieb“ auf Ihren eignen Servern oder von Ihnen gemieteten virtuellen Servern in einem Rechenzentrum (Co-Location)
- Als „Cloud Service“
In Kombination mit gesetzlichen und normativen Anforderungen – insbesondere in regulierten und akkreditierten Bereichen sind Sie mit Fragestellungen und Ängsten konfrontiert, die dieser Artikel behandeln wird.
Bei Ihnen geht nur „On-premises-Betrieb“?
Stellen Sie sich vor, Sie eröffnen einen neuen Standort und brauchen Strom. Ihr Facility Manager kommt und sagt: „Wir sollten ein eigenes Kraftwerk bauen. Dann haben wir die volle Kontrolle.“
Sie würden ihn vermutlich kurz ansehen und fragen: „Welche Kontrolle genau? Über die Kilowattstunden, die wir sowieso beziehen? Oder über den Aufwand, den wir definitiv nicht wollen?“
In der Softwarewelt passiert genau das regelmäßig. Nur heißt es dort nicht „eigenes Kraftwerk“, sondern „on-premises-Betrieb“ oder „wir wollen die Software in unserer eigenen Infrastruktur betreiben.“
Der Unterschied, der eigentlich keiner ist
Wenn jemand eine Buchhaltungssoftware kauft und auf seinem eigenen Server installiert, macht das Sinn. Er kauft ein Produkt. Er betreibt es. Er trägt die Verantwortung.
Aber nicht jede „Software“ ist ein Produkt, das man kauft und installiert.
Manche Software-Systeme sind von Grund auf als Infrastruktur gedacht — als etwas, das nicht nur aus einer Anwendung besteht, sondern aus dem gesamten Stack darunter: dem Betrieb, der Überwachung, den Updates, dem Backup, der Verfügbarkeit, der Sicherheitsarchitektur, den Zertifizierungen, den Schnittstellen und den Prozessen, die das alles am Laufen halten.
Diese Systeme nennt man Managed Services. Und der entscheidende Unterschied ist nicht, wo die Server stehen — sondern wie die Verantwortung zwischen Anwender und Anbieter sauber getrennt und vertraglich geregelt ist.
Managed Service: Was Sie wirklich bekommen — und was nicht
Bevor diese Frage sich klären lässt, muss eine andere geklärt sein: Wer ist wofür verantwortlich? Denn in regulierten Umgebungen — etwa in akkreditierten Laboratorien — verlangt die Norm ausdrücklich, dass die Verantwortung für das Managementsystem beim Anwender selbst liegt. Sie ist nicht delegierbar. Sie kann nicht durch einen Vertrag „weggekauft“ werden. Im Sinne der normativen Anforderungen sprechen wir von „Systemen, die nicht unter ständiger Kontrolle des Laboratorium stehen“ und von „Anforderungen an externe Produkte und Dienstleistungen“. Beides muss im Einklang mit den Anforderungen der zu Grunde liegenden normativen und gesetzlichen Anforderungen stehen.
Das bedeutet konkret: Das Laboratorium — oder allgemein der Betreiber der Anwendung — trägt die Verantwortung für die Prozesse, die Zugänge, die fachlichen Inhalte, die Datenqualität, die Validierung, die Schulung der Mitarbeitenden und die normgerechte Nutzung des Systems. Diese Verantwortung wandert in keinem Bereitstellungsmodell vollständig mit, egal ob On-Premises oder in der Cloud.
Was sich zwischen den Modellen unterscheidet, ist die Verantwortung für die Infrastruktur darunter und für die Sicherstellung der normativen und gesetzlichen Anforderungen an diese Infrastruktur. Und genau das ist der Punkt, an dem ein Managed Service eine besondere Konstruktion ist, die ihre Risiken in Bezug auf konformitätsbewertungsbezogene Informationssysteme minimiert und Fachkräfte entlastet.
Wenn Sie eine klassische Softwarelizenz kaufen, bekommen Sie einen Installationsassistenten und eine Dokumentation. Was danach kommt — Updates einspielen, Backups einrichten, Verfügbarkeit sicherstellen, Sicherheitslücken patchen, Logs schützen, Kapazitäten skalieren — das liegt bei Ihnen. Sie sind für das Managementsystem und für den Infrastrukturbetrieb verantwortlich.
Wenn Sie einen Managed Service beziehen, bleibt die Verantwortung für das Managementsystem bei Ihnen — was die Norm ohnehin verlangt. Aber die Verantwortung für die Informationssicherheit der Infrastruktur und die Einhaltung der normativen und gesetzlichen Anforderungen an diese Infrastruktur wird vertraglich geregelt und durch Lieferantensteuerung kontrolliert. Der Anbieter garantiert vertraglich, dass diese Anforderungen eingehalten werden — und liefert die Nachweise, die Sie als Anwender für Ihre Akkreditierung oder Zertifizierung brauchen.
Das ist die saubere Trennung: Sie tragen Ihre Verantwortung. Der Anbieter trägt die seine. Beides ist vertraglich abgesichert und durch Zertifikate prüfbar.
Aber was passiert mit der „Hoheit über Ihre Daten“? Von uns in der EU wird doch „Souveränität“ gefordert?
Aktueller Anlass: Was bedeutet „Souveränität“ eigentlich?
Neu im April 2026: Das Bundesamt für Sicherheit in der Informationstechnik hat den C3A — Criteria enabling Cloud Computing Autonomy veröffentlicht. Erstmals definiert eine offizielle Stelle, was „digitale Souveränität“ im Cloud-Kontext konkret bedeutet — aufgeteilt in sechs prüfbare Bereiche.
Das ist mehr als eine technische Veröffentlichung. Es ist der erste Versuch einer offiziellen Stelle, einen Begriff verbindlich zu definieren, der in den letzten Jahren in jeder Ausschreibung, in jedem Lastenheft, in jedem Vorstandsmeeting auftaucht — und der jedes Mal etwas anderes bedeutet hat: digitale Souveränität.
Das C3A teilt diesen schillernden Begriff in sechs prüfbare Bereiche auf. Wer wirklich wissen will, was Kontrolle im Cloud-Kontext bedeutet, findet hier zum ersten Mal eine sortierbare Antwort.
Und wenn man die sechs Bereiche durchgeht, fällt etwas auf: Nicht einer von ihnen verlangt physische Kontrolle über Server. Was sie verlangen, ist etwas anderes — und das ist der Punkt, an dem viele Gespräche über on-Premises-Betrieb eine überraschende Wendung nehmen.
Die Kontrolle-Frage — vier Ebenen, die meistens vermischt werden
Wenn jemand sagt: „Wir wollen die Kontrolle behalten“, meint er fast immer mehrere Dinge gleichzeitig. Das BSI hat diese Anliegen jetzt entwirrt — und es lohnt sich, die vier Ebenen einmal sauber zu trennen.
Erste Ebene: Wer bestimmt, wer auf Ihre Daten zugreift?
Das ist administrative Kontrolle. Sie verwalten Ihre Benutzer, Ihre Rollen, Ihre Berechtigungen. Diese Kontrolle gehört Ihnen — unabhängig davon, wo der Server steht. Sie ist eine Eigenschaft der Anwendung, nicht des Standorts.
Zweite Ebene: Wer haftet, wer kann auditiert werden, was passiert bei Vertragsende?
Das ist vertragliche Kontrolle. Sie entsteht durch saubere Verträge mit klaren Exit-Klauseln, Audit-Rechten und Vertraulichkeitsregelungen. Auch hier spielt der Serverstandort keine Rolle.
Dritte Ebene: Können Sie nachweisen, wo Ihre Daten liegen und wer Zugriff hat?
Das ist Nachweisbarkeit. Sie wird durch Zertifikate, unabhängige Prüfberichte und vertragliche Garantien erbracht. Kein Auditor verlangt dafür physischen Zutritt zum Rechenzentrum — er liest Dokumentation. Und in einem gut geführten Managed Service liegt diese Dokumentation bereit.
Vierte Ebene: Wer hat physischen Zutritt zum Server?
Das ist physische Kontrolle. Und das ist die einzige Form von Kontrolle, die ein eigener Serverbetrieb tatsächlich hinzufügt.
Die ehrliche Frage ist dann: Welche dieser vier Ebenen meinen Sie eigentlich, wenn Sie „Kontrolle“ sagen? Und welches reale Problem löst die vierte Ebene, das die ersten drei nicht bereits gelöst haben?
In den meisten Gesprächen stellt sich heraus: Was als Wunsch nach physischer Kontrolle formuliert wurde, ist in Wirklichkeit eine Anforderung an die ersten drei Ebenen. Und die sind in einem strukturierten Managed Service bereits vollständig adressiert.
Was sagen die Normen dazu?
Diese Frage stellen sich Verantwortliche in regulierten Umgebungen besonders häufig — etwa in akkreditierten Laboratorien, in zertifizierten Qualitätsmanagementsystemen oder in IT-sicherheitsrelevanten Organisationen. Die Antwort überrascht viele:
Keine einzige relevante Norm schreibt vor, wo „Software“ betrieben werden muss.
Weder die ISO 17025 für akkreditierte Laboratorien, noch die Datenschutz-Grundverordnung, noch das NIS2-Gesetz für IT-Sicherheit, noch der C3A-Rahmen selbst — keines dieser Regelwerke verlangt, dass Software auf eigenen Servern oder in einem vom Kunden gewählten Rechenzentrum läuft.
Was sie verlangen, sind die Ebenen eins bis drei: Wer hat Zugriff? Wo liegen die Daten? Welche Sicherheitsmaßnahmen gelten? Kann der Anbieter auditiert werden? Sind Lieferanten dokumentiert und steuerbar?
Das C3A geht hier sogar noch einen Schritt weiter: Es fordert ausdrücklich, dass physischer Zutritt zu Rechenzentren auf autorisiertes Personal beschränkt ist. Die Norm verlangt also gerade nicht, dass der Betreiber freien Zugang hat — sie verlangt das Gegenteil. Sicherheit entsteht durch kontrollierten Zutritt, nicht durch geteilten Zutritt.
Akkreditierten Laboren kommt dieser Anforderung ganz sicher bekannt vor.
Was passiert, wenn man trotzdem auf Eigenbetrieb besteht
Manchmal ist es eine bewusste Entscheidung: „Wir wissen, was das bedeutet, und wir wollen es trotzdem so.“ Das ist legitim und respektabel.
Aber es ist wichtig zu verstehen, was diese Entscheidung tatsächlich bedeutet — nicht als Warnung, sondern als ehrliche Beschreibung der Konsequenzen.
Sie übernehmen — zusätzlich zur ohnehin nicht delegierbaren Verantwortung für Ihr Managementsystem — auch die Verantwortung für Hardware, Netzwerk, Strom, Kühlung, Backup, Wiederherstellung nach Ausfall, Kapazitätsskalierung, Sicherheitszertifizierung der Infrastruktur und die Koordination aller dieser Punkte mit dem Softwareanbieter. Der Softwareanbieter kann Ihnen dann nur noch eine Anwendung liefern — keine durchgängige Verfügbarkeitsgarantie, kein Gesamtstack-Monitoring, kein einheitliches Incident-Management. Die normativen Nachweise für die Infrastruktur müssen Sie selbst oder über Ihren Rechenzentrumsbetreiber erbringen.
Aus C3A-Sicht: Wo vorher eine prüfbare Souveränitätskette stand (Softwareanbieter plus Hosting-Partner als Managed Service), entstehen plötzlich zwei voneinander unabhängige Ketten — der Softwareanbieter auf der einen Seite, der vom Kunden gewählte Rechenzentrumsbetreiber auf der anderen. Beide müssen gegen alle sechs C3A-Bereiche separat geprüft werden. Letzterer ist zum Zeitpunkt der Entscheidung typischerweise unbekannt.
Im besten Fall ist das Ergebnis gleichwertig mit einem gut betriebenen Managed Service. Der Weg dahin ist erheblich aufwendiger — und teurer.
Die eigentliche Frage
Wenn jemand sagt, er wolle „die Software bei sich betreiben“, lohnt sich seit April 2026 eine präzisere Gegenfrage:
Welche der sechs C3A-Souveränitätsbereiche sind in Ihrem Kontext konkret relevant — und welche davon sind durch das angebotene Managed-Service-Modell noch nicht erfüllt?
Diese Frage führt fast immer zu einer ehrlichen Bestandsaufnahme. Und sie führt fast immer zu der Erkenntnis, dass das, was als On-Premises-Wunsch begann, in Wirklichkeit eine berechtigte Anforderung an Datenstandort, Auditierbarkeit, Nachweisbarkeit und Lieferantensteuerung ist — die in einem strukturierten Managed Service bereits vollständig adressiert sein kann.
Der Unterschied liegt nicht im Serverstandort. Er liegt darin, wie die Verantwortung für die Infrastruktur und die normativen Nachweise organisiert wird — und ob die Souveränitätskette einmal oder zweimal nachgewiesen werden muss. Die Verantwortung für das Managementsystem selbst bleibt in beiden Modellen unverändert beim Anwender.
Was das für digitale Managementsysteme in akkreditierten Umgebungen bedeutet
Systeme, die für den Betrieb in akkreditierten Laboratorien oder regulierten Qualitätsmanagementsystemen entwickelt wurden, sind ein besonders klares Beispiel für dieses Prinzip. Das sind Systeme, die für diesen Zweck als Gesamtsystem als validiert gelten – auch dies sollte akkreditierten Laboratorien ein Begriff sein – genauso wie die Tatsache, das „Modifikationen“ an der Ausprägung solcher Systeme (etwa durch Änderung der Bereitstellungs-Infrastruktur) validiert werden müssen. Kommerzielle Systeme, die für diesen Zweck ausgelegt sind, gelten als validiert.
Sie sind nicht einfach Anwendungen, die man installiert. Sie sind vollständige Infrastrukturen: mit eingebauter Validierungsumgebung, unveränderlichem Audit Trail, georedundantem Backup, kontinuierlichem Sicherheitsmonitoring, definierten SLAs und einer regulatorischen Nachweiskette, die von der Norm bis zum Zertifikat durchgängig belegt ist.
Ein solches System aus dem Managed-Service-Kontext herauszulösen und in eine eigene Infrastruktur zu übertragen bedeutet nicht zwingend, mehr Kontrolle zu gewinnen. Es bedeutet vor allem, eine komplette Betriebsverantwortung zu übernehmen — für Infrastruktur, die bislang ein spezialisierter Anbieter im Griff hatte. Das überstiegt vor dem Hintergrund wachsender Anforderungen oft die Kompetenz vieler Unternehmen.
Fazit
Die Frage, ob Software „bei sich“ oder „beim Anbieter“ betrieben werden soll, ist seit der C3A-Veröffentlichung im April 2026 anders zu stellen als bisher. Sie ist keine Frage des Serverstandorts — sie ist eine Frage der Verantwortungsverteilung und der Souveränitätskette.
Wer als Verantwortlicher in einer regulierten Umgebung vor dieser Entscheidung steht, sollte sich fünf Dinge klar machen:
- Erstens: Die Verantwortung für das eigene Managementsystem ist normativ nicht delegierbar. Sie liegt — und bleibt — beim Anwender, unabhängig vom Bereitstellungsmodell.
- Zweitens: Was zwischen den Modellen variiert, ist nicht diese Kernverantwortung, sondern die Frage, wie die Infrastruktur-Verantwortung organisiert und wie deren normgerechte Erfüllung nachgewiesen wird.
- Drittens: Die meisten Anliegen, die unter dem Stichwort „Kontrolle“ zusammengefasst werden, sind administrativer, vertraglicher oder dokumentarischer Natur — und damit unabhängig vom Serverstandort.
- Viertens: Physische Kontrolle über Server ist von keiner einschlägigen Norm gefordert, im Gegenteil wird sie durch ISO 27001 und BSI C5 sogar ausdrücklich beschränkt.
- Fünftens: Wer den Eigenbetrieb wählt, übernimmt damit eine zweite Souveränitätskette, die separat nachgewiesen werden muss — typischerweise gegen einen Rechenzentrumsbetreiber, der zum Entscheidungszeitpunkt noch nicht ausgewählt ist.
Ein gut strukturierter Managed Service trennt diese Verantwortungen sauber: Der Anwender trägt seine normative Verantwortung für das Managementsystem. Der Anbieter garantiert vertraglich die Einhaltung der normativen und gesetzlichen Anforderungen an die Infrastruktur — und liefert die prüfbaren Nachweise, die der Anwender für seine Akkreditierung oder Zertifizierung braucht. Das ist es, wofür Sie ein Leistungsentgelt bezahlen.
Die richtige Frage lautet damit nicht „On-Premises oder Cloud?“, sondern: Welche der sechs C3A-Souveränitätsbereiche sind in Ihrem Kontext relevant — und wie werden sie in dem gewählten Modell nachweisbar adressiert? Bietet mein Cloud-Anbieter nur „Software-as-a-Service“ oder die gesamte Infrastruktur als Managed Service.
Das ist die Frage, die in jedem Lastenheft, jeder Ausschreibung und jedem Vorstandsmeeting zur digitalen Souveränität ab sofort am Anfang stehen sollte.
In eigener Sache
AUDITTRAILS Networks GmbH ist Anbieter einer vollständigen Infrastruktur als Managed Service für digitale Managementsysteme AUDITTRAILS-17025, AUDITTRAILS-15189 und AUDITTRAILS-27001 in akkreditierten und in zertifizierten Umgebungen — mit AUDITTRAILS LIMS als Laborinformations- und Managementsystem auf derselben Infrastruktur.
Das Bereitstellungsmodell ist nach ISO/IEC 27001:2022 (DEKRA) zertifiziert und nutzt eine nach BSI C5 Typ 2 testierte Hosting-Infrastruktur in Deutschland.
Wenn Sie wissen möchten, welche der sechs C3A-Souveränitätsbereiche in Ihrem konkreten Kontext relevant sind, sprechen Sie uns an.
