Platform Automation for Public Sector and Healthcare
BSI IT-Grundschutz module SYS.1.1, requirement A3: Restrictive permission assignment. Requirement A5: Interface protection. How do you demonstrate compliance on your 150 government servers?
BSI IT-Grundschutz and NIS2 define what public agencies and hospitals must implement and prove at platform level. The technical reality is heterogeneous: Linux servers, Windows systems, legacy specialist applications, often running in parallel and rarely fully documented. lennlay bridges the gap between regulatory requirement and technical evidence: automated, version-controlled, and running entirely within your own infrastructure.
Public sector IT caught between modernisation and security obligation
The public sector faces pressure from two directions: digitalisation programmes demand new technology, while regulatory obligations demand demonstrable security. Both at once, with limited resources and heterogeneous legacy estates.
The modernisation pressure
Introduce container technology, evaluate cloud services, replace legacy systems: national and state digitalisation strategies set clear targets. Agencies and hospitals are expected to modernise, often while keeping operations running and without putting critical specialist applications at risk.
Older Linux servers cannot simply be replaced. Specialist applications have dependencies that are rarely fully documented. Every change carries risk. Staffing is thin.
The security obligation
BSI IT-Grundschutz specifies requirements per module. Every server is subject to the baseline and standard requirements of SYS.1.1 and SYS.1.3. Every web server falls under APP.3.2. None of this is optional, and every requirement must be demonstrable when an audit arrives.
Germany's NIS2 implementation act (NIS2UmsuCG) classifies state-level agencies as essential entities as of October 2024. Hospitals are explicitly covered by NIS2. The KRITIS-Verordnung adds further obligations for critical infrastructure operators. These frameworks overlap and demand the same evidence: documented hardening, auditable configurations, incident reporting.
From module requirement to platform configuration
IT-Grundschutz modules describe what must be in place. lennlay translates that into concrete, verifiable configurations and delivers the compliance evidence automatically alongside.
General server
A3 Restrictive permission assignment: Service accounts with minimal privileges, least-privilege sudo rules, no unnecessary privileged user accounts.
A5 Interface protection: SSH hardening, unnecessary services disabled, network services configured restrictively.
lennlay: Automated Linux baseline covering these requirements. Evidence delivered as a structured audit report for reviewers and auditors.
Servers running Unix/Linux
Linux-specific requirements: SELinux or AppArmor, file system permissions, kernel hardening parameters, structured update management.
System services minimised, no default passwords, logging configuration per IT-Grundschutz specification, integrity checking for critical files.
lennlay: RHEL-based platform with SELinux enforcing, automated patch management, versioned baselines with a full change history.
Under developmentWeb server
Apache HTTPD or IIS: current-state TLS configuration, security headers, module restrictions, directory listing disabled.
Version information suppressed, server tokens minimised, access control and authentication configured per BSI requirements.
lennlay: Ansible Collection for Apache HTTP Server available in the community catalogue. Hardening aligned with APP.3.2 requirements, fully documented.
Containers and Kubernetes
For agencies introducing container technology: CON.8 sets requirements for software development and deployment pipelines; APP.4.4 covers Kubernetes clusters, pod security profiles, and network segmentation.
Both modules apply to platforms running containerised specialist applications.
lennlay: Platform extension for container hardening in concept phase. BSI-aligned Kubernetes baselines planned.
In concept phaseNIS2 for public agencies and healthcare
Germany's NIS2 implementation act has been in force since October 2024. State-level agencies and hospitals are classified as essential entities and fall within its scope.
Public agencies as essential entities
State-level agencies and a range of federal authorities are classified as essential entities under NIS2UmsuCG. Article 21 mandates concrete action: risk management, technical protection measures, supply chain governance, and incident reporting obligations for significant events.
At platform level, this means: documented hardening standards, automated compliance assessment, verifiable incident detection, and a complete configuration history. None of these requirements can be met sustainably without a standardised platform baseline.
Hospitals and healthcare
Hospitals are explicitly listed as essential entities in both the NIS2 Directive and in NIS2UmsuCG. The threshold applies to hospitals with more than 250 employees and facilities with specific infrastructure for medical care.
The IT platforms running patient data, medical records, and clinical systems fall within NIS2 scope. The technical requirements are the same: evidenced hardening, automated compliance runs, configuration management with a traceable change history. lennlay covers the platform layer of these obligations.
No cloud obligation: fully on-premises
Public agencies often face legal or security-policy requirements to operate within their own infrastructure. lennlay works exclusively on-premises.
Ansible Collections run locally within your infrastructure. GIaaS baselines are delivered as versioned artefacts, not as a SaaS service. No network traffic to external platforms, no cloud account, no risk of data leaving your environment.
This aligns with the requirements of agencies that must maintain data sovereignty and comply with IT security classification requirements set by BSI. If you do not need a cloud offering, you will not receive one.
All lennlay components run within your own infrastructure. No external dependency, no SaaS platform, no cloud connection required.
Platform security for the public sector
Linux baselines per BSI
Automated RHEL hardening aligned with SYS.1.1 and SYS.1.3. Documented baseline, version-controlled, audit-ready. Implemented via the lennlay.core Ansible Collection.
Compliance evidence
Automated scanner compares running systems against the BSI-referenced baseline. Structured report usable directly by BSI auditors, internal reviewers, and data protection officers.
Ansible automation
lennlay.community Collection available free of charge on Ansible Galaxy. lennlay.core and platform-specific Collections in the Enterprise tier for systematic standardisation across all servers.
EaaS for public sector projects
Marcel König (RHCA/RHCE) and Matthias Siegl for embedded engagements: platform assessment, hardening implementation, compliance documentation for IT-Grundschutz audits.
Lifecycle management
OS end-of-life tracking for RHEL versions, structured security update management, KRITIS-relevant systems tracked separately, prioritised, and documented.
On-premises operation
No cloud dependency, no SaaS. All components run within your infrastructure: suitable for agencies with requirements around data sovereignty and BSI IT security classifications.
Three typical starting situations
BSI IT-Grundschutz evidence
An IT-Grundschutz audit is approaching. Module requirements must be documented and technically evidenced. Manually operated platforms cannot produce this evidence without significant effort.
NIS2 implementation
NIS2UmsuCG applies. The agency or hospital has been classified as an essential entity. Article 21 measures must be implemented at platform level and demonstrated to the competent authority.
Modernisation with operations running
Older Linux servers are scheduled to migrate to a current RHEL version or a container platform. The security standard must remain the same or improve during the transition, without interrupting specialist applications.
BSI IT-Grundschutz modules describe requirements, not configuration recipes. Many platforms in public agencies and hospitals are largely secure in technical terms, but the evidence is missing. lennlay brings both together: platform configuration that meets the current state of the art and automated evidence delivery that stands up under audit scrutiny.
BSI IT-Grundschutz and NIS2 affect your platforms. We help you build the technical evidence that proves it.
