In den meisten Arztpraxen rechnet sich Infrastructure as Code nicht. Der Begriff bezeichnet die Verwaltung technischer Infrastruktur über versionierte Konfigurationsdateien und automatisierte Abläufe statt über wiederholte manuelle Einrichtung. Das kann sehr nützlich sein. Für einet ypische Einzelpraxis ist es jedoch meist eine unnötig aufwendige Lösung für ein Problem, das dort kaum auftritt.

Die Entscheidung lässt sich auf drei Bedingungen reduzieren. Es müssen mehrere weitgehend gleichartige Umgebungen vorhanden sein, diese Umgebungen müssen regelmäßig neu aufgebaut oder wiederhergestellt werden, und die Organisation muss die zugrunde liegende Infrastruktur selbst kontrollieren. Fehlt nur eine dieser Voraussetzungen, ist IaC in der Regel nicht wirtschaftlich.

Drei Bedingungen, die gleichzeitig erfüllt sein müssen

Die erste Bedingung ist Wiederholung. Infrastructure as Code lohnt sich dort, wo mehrere Standorte mit nahezu identischer Technik betrieben werden. Firewalls, Netzwerksegmente, Benutzerrollen und Sicherheitsrichtlinien folgen dann dem selben Grundmodell und unterscheiden sich nur durch wenige Parameter wie IP-Bereiche, Standortnamen oder lokale Zugangsdaten.

Eine einzelne Praxis besitzt diese Wiederholung nicht. Sie hat eine konkrete Firewall, ein Netzwerk und eine überschaubare Zahl von Arbeitsplätzen. Die Automatisierung der Bereitstellung spart wenig, wenn die Umgebung nur einmal eingerichtet und anschließend über Jahre weiterbetrieben wird. Interessant wird das Verfahren eher für größere Praxisgruppen oder MVZ-Strukturen, die denselben technischen Stack an vielen geografisch getrennten Standorten einsetzen.

Die zweite Bedingung ist ein tatsächlicher Bedarf an wiederholtem Neuaufbau. IaC spielt seine Stärke aus, wenn eine Umgebung regelmäßig zurückgesetzt, reproduziert oder nach einem Ausfall vollständig wiederhergestellt werden muss. Das kann Firewall-Konfigurationen,Netzwerksegmentierung oder eine definierte Endpoint-Baseline betreffen.

Der normale Praxisbetrieb sieht anders aus. Nach unserer Erfahrung lassen sich rund 99 Prozent der Supportfälle remote lösen. Diese Zahl ist ein Erfahrungswert aus dem eigenen Betrieb und keine allgemeine Branchenstatistik. Sie zeigt dennoch, weshalb der wiederholte vollständige Neuaufbau für die typische Praxis kein prägender Anwendungsfall ist: Meist wird ein bestehendes System repariert, aktualisiert oder angepasst, nicht neu erzeugt.

Die dritte Bedingung ist die Kontrolle über die Infrastruktur. Automatisieren lässt sich nur, was über geeignete Schnittstellen, Skripte und definierte Konfigurationswege steuerbar ist. Wer überwiegend Standardsoftware nutzt, deren Installationslogik und Datenhaltung vom Hersteller vorgegeben werden, kann diese Kontrolle nur eingeschränkt herstellen.

Damit erfüllt die typische Einzelpraxis keine der drei Voraussetzungen vollständig. Sie betreibt keine große Zahl gleichartiger Umgebungen, baut ihre Infrastruktur nicht regelmäßig neu auf und kontrolliert wesentliche Teile der eingesetzten Fachsoftware nicht selbst. In dieser Konstellation entsteht der Automatisierungsaufwand, ohne dass genügend Wiederholungen vorhanden sind, über die er sich auszahlen könnte.

Die eigentliche Arbeit beginnt vor der erstenKonfigurationsdatei

Die größte Hürde liegt nicht in Terraform, Ansible oder einem anderen IaC-Werkzeug. Sie liegt in der Architektur der Anwendungen. Damit eine Umgebung zuverlässig automatisiert aufgebaut und wiederhergestellt werden kann, müssen Applikation, Konfiguration und Daten sauber von einander getrennt sein.

Bei vielen Fachanwendungen im Gesundheitswesen ist diese Trennung nicht vorgesehen. Ein konkretes Beispiel aus unserer Praxis ist Medical Office: Die Standardinstallation lässt sich nicht einfach als austauschbarer Applikationsbaustein über Infrastructure as Code bereitstellen. Zunächst wären zusätzliche Skripte und Anpassungen erforderlich, um Programmbestandteile und Datenhaltung so voneinander zu trennen, dass sich die Anwendung reproduzierbar installieren lässt.

Der Aufwand entsteht damit vor dem ersten eigentlichen IaC-Konfigurationsfile. Installationsroutinen müssen analysiert,unbeaufsichtigte Abläufe entwickelt, Datenpfade ausgelagert und Wiederherstellungsverfahren getestet werden. Jede Änderung des Herstellers kann diese Anpassungen erneut betreffen.

Für eine Umgebung, die an vielen Standorten identisch ausgerollt wird, kann diese Vorarbeit sinnvoll sein. Für eine einzelne Praxis bedeutet sie häufig, eine herstellerseitig nicht vorgesehene Automatisierung dauerhaft selbst pflegen zu müssen. Das ist kein Produktivitätsgewinn, sondern eine zusätzliche technische Abhängigkeit.

NIS2 ist für die meisten Praxen kein IaC-Argument

Infrastructure as Code wird teilweise mit NIS2 begründet. Das klingt plausibel, weil automatisierte Konfigurationen nachvollziehbar ,versionierbar und wiederholbar sind. Für die meisten niedergelassenen Praxen greift dieses Argument jedoch nicht.

Das deutsche NIS2-Umsetzungsgesetz ist seit dem 6.Dezember 2025 in Kraft. Eine Arztpraxis oder ein MVZ wird im Regelfall erst ab den Größenschwellen des § 28 BSIG als wichtige Einrichtung erfasst: mindestens 50 Beschäftigte oder ein Jahresumsatz von mehr als zehn Millionen Euro bei einer Bilanzsumme von ebenfalls mehr als zehn Millionen Euro. Einzelpraxen und typische kleinere Berufsausübungsgemeinschaften fallen damit grundsätzlich nicht unter diese Einstufung.

Selbst für betroffene Einrichtungen schreibt NIS2 kein bestimmtes Automatisierungsprodukt vor. Die gesetzlichen Vorgaben zielen auf Risikomanagement, angemessene Sicherheitsmaßnahmen und Meldeprozesse. Ob ein Ziel mit IaC, einem zentralen Managementsystem oder dokumentierten manuellen Verfahren erreicht wird, hängt von der Architektur und der Größe der Organisation ab.

Aus unserer Erfahrung wird NIS2 dennoch häufig als Verkaufsargument für technische Produkte verwendet. Dabei sind organisatorische Maßnahmen meist schwieriger umzusetzen als die technische Grundkonfiguration: Verantwortlichkeiten müssen geklärt, Vorfälle bewertet, Zugriffe freigegeben und Prozesse tatsächlich gelebt werden. IaC kann diese Entscheidungen dokumentieren, aber nicht treffen.

Der ehrlichere Anknüpfungspunkt ist die KBV-Richtlinie

Für Arzt- und Psychotherapiepraxen ist die IT-Sicherheitsrichtlinie nach § 390 SGB V derdeutlich nähere Bezugspunkt. Sie wurde von der KBV im Einvernehmen mit dem BSI erstellt und gilt in ihrer neuen Fassung seit Oktober 2025 für rund 99.000 Arzt- und Psychotherapiepraxen. Die Anforderungen sind nach Praxisgröße und Ausstattung gestaffelt.

Die Richtlinie verlangt unter anderem klarebVerantwortlichkeiten, regelmäßige Datensicherung, geregelte Berechtigungen,sichere Konfigurationen und dokumentierte Entscheidungen. Das BSI weist zudem darauf hin, dass die Vorgabenjährlich überprüft und regelmäßig an Bedrohungslage und Stand der Technikangepasst werden sollen.

Hier liegt ein sinnvoller Bezug zur Reproduzierbarkeit. EinePraxis muss nachvollziehen können, wie ihre Firewall, ihre Zugriffsrechte undihre Endgeräte abgesichert sind. Sie muss außerdem erkennen können, ob deraktuelle Zustand noch dem freigegebenen Stand entspricht.

Daraus folgt aber nicht automatisch, dass Infrastructure asCode erforderlich ist. Bei einem Standort kann eine sauber gepflegteKonfigurationsdokumentation ausreichen. Erst wenn dieselben Kontrollen überviele gleichartige Standorte hinweg wiederholt, verglichen und nach Änderungenerneut ausgerollt werden müssen, beginnt IaC einen strukturellen Vorteil zubieten.

Was die meisten Praxen stattdessen benötigen

Das eigentliche Ziel ist kein bestimmtes Werkzeug, sondern ein dokumentierter und reproduzierbarer Konfigurationszustand. Eine Praxissollte wissen, welche Firewall-Regeln gelten, wie ihr Netzwerk segmentiert ist,welche Administratorrechte vergeben wurden und wie ein System nach einem Defekt wiederhergestellt wird.

Dieser Zustand kann mit exportierten Konfigurationen,dokumentierten Baselines, kontrollierten Änderungen und getesteten Wiederherstellungsabläufen erreicht werden. Bei wachsenden Standortstrukturen kann daraus später schrittweise Infrastructure as Code entstehen. Die Dokumentation wird dann nicht ersetzt, sondern in automatisierbare Regeln überführt.

IaC rechnet sich erst, wenn gleichartige Infrastruktur häufig genug reproduziert werden muss und die Organisation sie technisch kontrollieren kann. Für die einzelne Praxis ist die richtige Entscheidung deshalb meistens, auf den Werkzeugkauf zu verzichten und zunächst den vorhandenen Zustand sauber beherrschbar zu machen.

‍

FAQ: Infrastructure-as-Code

Ab wie vielen Standorten lohnt sich Infrastructure asCode?

Eine feste Standortzahl lässt sich seriös nicht nennen. Entscheidend ist, wie ähnlich die Umgebungen sind und wie häufig dieselben Konfigurationen eingerichtet oder verändert werden. Zehn stark unterschiedliche Standorte können weniger Automatisierungspotenzial bieten als wenige nahezu identische Umgebungen.

Braucht eine Einzelpraxis IaC für ihre Firewall?

In der Regel nicht. Eine dokumentierte Konfiguration, regelmäßige Sicherungen und ein getesteter Wiederherstellungsweg liefern meistden relevanten Nutzen. IaC wird erst interessant, wenn dieselbe Firewall-Baseline wiederholt auf mehrere Systeme ausgerollt werden soll.

Ist IaC notwendig, um die KBV-IT-Sicherheitsrichtlinie zuerfüllen?

Nein. Die Richtlinie beschreibt Sicherheitsanforderungen und keinen vorgeschriebenen technischen Lösungsweg. IaC kann bei größeren Strukturen die Dokumentation und einheitliche Umsetzung unterstützen, ist aber keine Voraussetzung für regelkonformen Betrieb.

Macht NIS2 Infrastructure as Code verpflichtend?

Nein. NIS2 verlangt keine bestimmte Automatisierungssoftware.Zudem erreichen Einzelpraxen und typische kleine Gemeinschaftspraxen die gesetzlichen Größenschwellen im Regelfall nicht.

Was sollte vor einer IaC-Einführung geprüft werden?

Zuerst muss geklärt werden, ob Applikationen, Konfigurationen und Daten technisch voneinander getrennt werden können. Danach ist zu prüfen, wie oft die Umgebung tatsächlich reproduziert wird und ob ausreichend gleichartige Systeme vorhanden sind. Lassen sich diese Fragen nicht klar beantworten, ist Infrastructure as Code meist nicht der richtige nächste Schritt.

‍