For most medical practices, Infrastructure as Code is not cost-effective. The term refers to managing technical infrastructure through version-controlled configuration files and automated workflows rather than repetitive manual setup. While this can be very useful, for a typical solo practice, it is usually an unnecessarily complex solution to a problem that rarely occurs there.

The decision comes down to three conditions. There must be multiple, largely identical environments; these environments must be regularly rebuilt or restored; and the organization must control the underlying infrastructure itself. If even one of these requirements is missing, IaC is generally not economical.

Three conditions that must be met simultaneously

The first condition is repetition. Infrastructure as Code is worthwhile where multiple locations are operated with nearly identical technology. Firewalls, network segments, user roles, and security policies then follow the same basic model, differing only by a few parameters such as IP ranges, location names, or local credentials.

A single practice does not have this repetition. It has one specific firewall, one network, and a manageable number of workstations. Automating deployment saves little if the environment is set up once and then operated for years. The approach becomes interesting primarily for larger practice groups or medical care centers (MVZs) that deploy the same technical stack across many geographically separate locations.

The second condition is an actual need for repeated rebuilding. IaC shows its strength when an environment must be regularly reset, reproduced, or fully restored after a failure. This can apply to firewall configurations, network segmentation, or a defined endpoint baseline.

Normal practice operations are different. In our experience, about 99 percent of support cases can be resolved remotely. This figure is based on our own operations and is not a general industry statistic. Nevertheless, it shows why a complete, repeated rebuild is not a defining use case for a typical practice: usually, an existing system is repaired, updated, or adjusted, not recreated from scratch.

The third condition is control over the infrastructure. You can only automate what can be controlled via suitable interfaces, scripts, and defined configuration paths. Those who primarily use standard software, where the installation logic and data storage are dictated by the manufacturer, can only achieve this control to a limited extent.

Consequently, the typical solo practice does not fully meet any of the three requirements. It does not operate a large number of identical environments, does not regularly rebuild its infrastructure, and does not control essential parts of the specialized software it uses. In this scenario, the effort of automation is incurred without enough repetition to make it pay off.

The real work begins before the first configuration file

The biggest hurdle is not Terraform, Ansible, or any other IaC tool. It lies in the architecture of the applications. For an environment to be reliably built and restored automatically, the application, configuration, and data must be cleanly separated from one another.

For many specialized healthcare applications, this separation is not provided for. A concrete example from our practice is Medical Office: the standard installation cannot simply be deployed as an interchangeable application module via Infrastructure as Code. Additional scripts and adjustments would first be required to separate program components and data storage in such a way that the application can be installed reproducibly.

The effort therefore arises before the first actual IaC configuration file. Installation routines must be analyzed, unattended workflows developed, data paths offloaded, and recovery procedures tested. Any change by the manufacturer can affect these adjustments all over again.

For an environment that is rolled out identically at many locations, this preparatory work can make sense. For a single practice, it often means having to permanently maintain an automation that the manufacturer did not intend. This is not a productivity gain, but an additional technical dependency.

NIS2 is not an argument for IaC

Infrastructure as Code is sometimes justified by citing NIS2. This sounds plausible because automated configurations are traceable, versionable, and repeatable. However, for most established practices, this argument does not hold water.

The German NIS2 implementation act has been in effect since December 6, 2025. A medical practice or an MVZ is generally only classified as an important entity once it meets the size thresholds of Section 28 of the BSIG: at least 50 employees or an annual turnover of more than ten million euros with a balance sheet total also exceeding ten million euros. Solo practices and typical smaller group practices therefore generally do not fall under this classification.

Even for affected institutions, NIS2 does not mandate any specific automation product. The legal requirements focus on risk management, appropriate security measures, and reporting processes. Whether a goal is achieved with IaC, a central management system, or documented manual procedures depends on the architecture and size of the organization.

In our experience, NIS2 is nevertheless frequently used as a sales argument for technical products. Yet, organizational measures are usually more difficult to implement than the basic technical configuration: responsibilities must be clarified, incidents assessed, access rights granted, and processes actually put into practice. IaC can document these decisions, but it cannot make them.

The more honest starting point is the KBV directive

For medical and psychotherapy practices, the IT security directive according to § 390 SGB V is the much more relevant reference point. It was created by the KBV in agreement with the BSI and, in its new version, has applied to around 99,000 medical and psychotherapy practices since October 2025. The requirements are tiered based on practice size and equipment.

The directive requires, among other things, clear responsibilities, regular data backups, regulated access rights, secure configurations, and documented decisions. The BSI also points out that these requirements should be reviewed annually and regularly adapted to the threat landscape and the state of the art.

This is where a meaningful connection to reproducibility lies. A practice must be able to track how its firewall, access rights, and end devices are secured. It must also be able to determine whether the current state still corresponds to the approved standard.

However, it does not automatically follow that Infrastructure as Code is required. For a single location, a cleanly maintained configuration documentation may be sufficient. Only when the same controls need to be repeated across many similar locations, compared, and redeployed after changes does IaC begin to offer a structural advantage.

What most practices need instead

The actual goal is not a specific tool, but a documented and reproducible configuration state. A practice should know which firewall rules apply, how its network is segmented, which administrator rights have been granted, and how a system is restored after a failure.

This state can be achieved with exported configurations, documented baselines, controlled changes, and tested recovery procedures. As location structures grow, this can gradually evolve into Infrastructure as Code. The documentation is then not replaced, but rather converted into automatable rules.

IaC only pays off when similar infrastructure needs to be reproduced frequently enough and the organization has the technical capability to control it. For the individual practice, the right decision is therefore usually to forgo purchasing tools and instead focus on making the existing state cleanly manageable.

‍

FAQ: Infrastructure as Code

At which size does Infrastructure as Code become worthwhile?

It is not possible to provide a reliable fixed number of locations. The decisive factor is how similar the environments are and how frequently the same configurations are set up or changed. Ten highly different locations may offer less automation potential than a few nearly identical environments.

Does a single practice need IaC for its firewall?

Generally, no. A documented configuration, regular backups, and a tested recovery path usually provide the relevant benefits. IaC only becomes interesting when the same firewall baseline needs to be repeatedly rolled out to multiple systems.

Is IaC necessary to comply with the KBV IT security directive?

No. The directive describes security requirements, not a prescribed technical solution. While IaC can support documentation and consistent implementation in larger structures, it is not a prerequisite for compliant operation.

Does NIS2 make Infrastructure as Code mandatory?

No. NIS2 does not require any specific automation software. Furthermore, individual practices and typical small group practices generally do not meet the legal size thresholds.

What should be checked before introducing IaC?

First, you need to determine whether your applications, configurations, and data can be technically separated. Next, examine how often your environment is actually reproduced and whether you have enough similar systems. If you cannot answer these questions clearly, Infrastructure as Code is usually not the right next step.

‍