Kubernetes in Regulated Industries: What You Need to Know

Kubernetes has long been the standard in startups and tech companies. But what about industries where data protection, regulatory compliance, and auditability are not optional features? Hospitals, banks, and government agencies operate under very different conditions than a SaaS startup. Anyone who wants to use Kubernetes in these settings must think differently from the very beginning.

This article explains what really matters in the healthcare sector, the financial industry, and public administration—and how you can set the right course from the very beginning.

What are regulated industries?

Regulated industries are subject to particularly strict legal, technical, and organizational requirements.

These include, among other things:

• Health Care
• Banks and Financial Service Providers
• Insurance
• public administration
• critical infrastructure
• Energy provider
• Telecommunications

Why Regulated Industries Have Special Requirements

In regulated environments, it’s not just about getting the application up and running. Rather, it must be possible to demonstrate that it operates securely—to auditors, regulators, and, if necessary, in court.

In practice, this means:

• Traceability: Any change to configurations or access rights must be traceable.
• Data sovereignty: Personal data or security-critical data may only be stored and processed in specified regions.
• Availability: SLAs are not a wish list, but a contractual or legal obligation.
• Separation of responsibilities: The person responsible for deployment must not have access to production data at the same time, not even through technical means. Therefore, access control must be clearly defined.
• Data Protection: Personal data may only be processed for specific purposes and must be technically protected against unauthorized access.
• Information security: The confidentiality , integrity, and availability of systems are not optional—they are legal or contractual obligations and must be verifiably ensured through specific technical measures.
• Documentation: Auditors do not want statements; they want evidence: every configuration decision, every access right, and every change to the cluster must be documented in writing.
• Risk Management: Risks must not only be identified, but also assessed, prioritized, and addressed with specific measures. An informal “We’ve got that under control” approach is simply not enough in regulated environments.

Why Kubernetes Is Becoming Increasingly Important for Regulated Industries

Kubernetes has evolved from a modern developer platform into a core infrastructure technology for enterprises. Interest in containerized platforms and cloud-native architectures is growing, particularly in regulated industries such as healthcare, the financial sector, and public administration.

The reason for this is obvious: Today, companies and government agencies must simultaneously:

• provide highly available digital services,
• protect sensitive data,
• comply with regulatory requirements,
• scale flexibly and
• Innovations must be implemented more quickly.

Kubernetes offers enormous advantages in this regard. At the same time, however, the requirements for security, data protection, governance, and compliance are increasing.

Regulated industries, in particular, are subject to strict legal requirements. Configuration errors or security vulnerabilities can not only result in financial losses, but also lead to legal consequences and a loss of trust.

Kubernetes in Healthcare

Regulatory Framework: GDPR, DIGA Requirements, and More

Requirements are particularly stringent in the healthcare sector. Patient data is subject not only to the GDPR, but also to medical confidentiality and, depending on the specific use case, to the requirements of the Digital Healthcare Act (DVG) and the BSI’s guidelines for KRITIS operators.

Digitalization in the Healthcare Sector

Hospitals, clinics, and healthcare providers are increasingly digitizing their processes.

These include:

• electronic health records
• Telemedicine
• Health Portals
• Mobile health apps.
• AI-powered diagnostics

Kubernetes helps deliver modern applications in a scalable way.

Specifically, this means the following for running Kubernetes in the healthcare sector:

• Encryption: Data encryption is mandatory, both at rest and in transit. etcd must be run with encryption enabled, and TLS must be used between all cluster components.
• Data in Germany: As a general rule, patient data may not be stored on servers outside the EEA. In practice, many institutions explicitly prefer German data centers.
• Data-Level Access Control: RBAC at the Kubernetes level is not sufficient. Who is allowed to access which patient data must be controlled and logged at the application level.
• Audit Trails for Auditors: Not only technical events, but also business-related access to patient records must be traceable.
• Protection of Personal Health Data: Under Article 9 of the GDPR, health data is classified as a special category of data requiring enhanced protection. Access must be limited to the absolute minimum necessary and enforced through technical measures, not merely regulated through organizational controls.
• High Availability: In the medical field, a system failure can directly jeopardize patient care. Kubernetes clusters in the healthcare sector must therefore be designed for high availability and include redundant control plane components as well as defined SLAs.
• Disaster Recovery: A documented and regularly tested recovery plan is mandatory. In the event of a disaster, it must be possible to demonstrate that data can be fully restored and how long that will take (RTO/RPO).

Case Study: Telemedicine Platform

A telemedicine platform that manages video consultations and patient data runs its services on Kubernetes. The critical design decisions: Patient data and metadata run in separate namespaces with strict network policies. No pod outside the patient-data namespace is allowed to access the database services directly. Secrets are not stored in Kubernetes but are injected via an external Vault service. All API calls to patient-related endpoints are logged in a central SIEM.

Best Practices for Kubernetes in Healthcare:

Strict access controls

Since access to medical data must be strictly regulated.

Key Measures:

• Use RBAC
• Multi-factor authentication
• Least Privilege Principle
• central identity provider

Encryption of Sensitive Data

All sensitive data should be encrypted.

• in sleep mode
• during the broadcast
• for backups

Network Segmentation

Medical systems should be isolated from one another.

With Kubernetes Network Policies, you can:

• Monitor data flows and
• Prevent lateral movements.

Kubernetes in the Financial Industry

Regulatory Framework: MaRisk, DORA, and PCI-DSS

Banks, insurance companies, and payment service providers operate in one of the most heavily regulated environments imaginable. In addition to the GDPR, the Minimum Requirements for Risk Management (MaRisk), the EU Digital Operational Resilience Act (DORA), and—for payment data—PCI-DSS all come into play.

DORA has been mandatory since January 2025 and imposes specific requirements on digital operational resilience: Financial institutions must be able to demonstrate that their IT systems—including cloud infrastructures and Kubernetes clusters—are resilient to outages and cyberattacks.

Digital Transformation of Banks and Financial Service Providers

Banks are increasingly modernizing their applications using cloud-native technologies.

Typical areas of application:

• Online Banking
• Payment Platforms
• Trading Systems
• Fraud Detection
• Mobile Banking
• FinTech Applications

Kubernetes enables rapid scaling and high availability.

In practical terms, this means the following for Kubernetes operations:

• High Availability by Design: Control plane components must be deployed redundantly. Single points of failure are not tolerated in a DORA-compliant setup.
• Change Management: Every change made to the cluster—including a Kubernetes upgrade—must be documented, approved, and auditable afterward.
• Supplier Risk Management: Anyone using Managed Kubernetes must treat their provider as an IT service provider as defined by DORA. This includes regular risk assessments and contractual safeguards.
• Penetration Tests: DORA requires systemically important institutions to conduct regular TLPTs (Threat-Led Penetration Tests).
• Continuous Monitoring: Financial systems must be monitored continuously. Key areas of monitoring include: API access, network activity, anomalies, security incidents, and user activity.
• Secure CI/CD Pipelines: CI/CD processes must be protected against tampering. This includes signed container images, automated security scans, policy enforcement, and supply chain security.
• Highly Available Architectures: Banking systems require minimal downtime. Kubernetes supports this with multi-zone deployments, automatic scaling, redundant services, and self-healing.
• PCI-DSS: Cardholder data may only be processed in segmented namespaces explicitly designated for that purpose. Network policies must fully control traffic to and from CDE (Cardholder Data Environment) components. All access to CDE namespaces must be logged and regularly reviewed. Image scanning is mandatory: Only verified, signed container images may be executed in CDE-relevant namespaces.

Case Study: Online Banking Platform

A direct bank that runs its online banking and mobile app services on Kubernetes faces traditional financial compliance requirements: PCI-DSS for payment data, DORA for operational resilience, and MaRisk for internal risk management. The critical design decisions:

Payment data and transaction logic run exclusively in the dedicated cde namespace (Cardholder Data Environment). Strict network policies prevent any direct communication with other namespaces. In addition, all container images are automatically scanned for vulnerabilities before deployment, and only signed images from the internal registry are permitted. Secrets such as API keys for payment service providers are never stored in Kubernetes but are injected at runtime from a hardened Vault service. All access to the CDE namespace is logged in real time in the central SIEM—including automatic alerts for unusual access patterns.

Best Practices for Kubernetes in the Financial Industry

Strict Network Segmentation

Financial data and payment processes must be isolated from all other workloads.

With Kubernetes Network Policies, you can:

• Strictly isolate cardholder data environments.
• Prevent lateral movements after an initial drop.

Complete auditability

Regulators such as BaFin and PCI-DSS auditors expect full traceability.

Key Measures:

• Enable Kubernetes audit logging and aggregate it centrally.
• Log all accesses to finance-related namespaces.
• Log retention in accordance with regulatory requirements (MaRisk: at least 5 years).
• Schedule regular reviews of the audit trails.

Change Management and GitOps

Any change to the cluster must be documented, approved, and traceable, as this is explicitly required by DORA and MaRisk.

In practice, this means:

• All configuration changes are made via Git commits.
• No manual access to production namespaces.
• Deployments are managed via ArgoCD or Flux and are fully auditable.

Supply Chain Security

In the financial industry, the question of what’s going on behind the scenes is not a rhetorical one.

Key Measures:

• Automatic image scanning for known CVEs before each deployment.
• Image signing with Cosign/Sigstore as a mandatory step in the CI/CD pipeline.
• Software Bill of Materials (SBOM) for all production container images.
• Allow only images from your own hardened registry.

Kubernetes in Public Administration

Regulatory Framework: BSI Basic Protection and EVB-IT

Government agencies and public institutions in Germany follow the BSI Basic Protection Framework, one of the most comprehensive security frameworks in existence. Anyone operating Kubernetes for administrative applications must secure the cluster in accordance with the relevant components and document this as part of an Information Security Management System (ISMS).

In addition, there are requirements under public procurement law. Cloud services for the public sector must demonstrate compliance with certain certifications, such as the BSI’s C5 (Cloud Computing Compliance Criteria Catalogue) or ISO 27001.

Digital Government and E-Government

Government agencies are increasingly modernizing their IT systems.

Examples:

• Citizen Portals
• Online Applications
• Registry Systems
• Management Platforms

Kubernetes enables a more flexible and efficient deployment of these applications.

Practical implications for Kubernetes operations:

• No public cloud hyperscaler without due diligence: For many administrative applications, storing data with U.S. providers is problematic for legal reasons. German or European providers with proven C5/ISO certification have a clear advantage here.
• Strict network segregation: Administrative applications that process citizen data must not share any network layers with other applications.
• Documentation Requirements: The BSI Basic Protection Framework requires comprehensive system documentation that covers all Kubernetes configurations, RBAC settings, and network policies.
• Open Source: Open-source solutions are preferred in order to avoid vendor lock-in and to be able to review the source code.
• IT Security: Kubernetes clusters in government agencies must be hardened in accordance with the BSI’s Basic Protection Guidelines and regularly scanned for vulnerabilities, as threat landscapes and requirements are constantly evolving and a one-time setup is not sufficient.
• Availability: Administrative applications that serve citizens or support internal processes cannot simply go down. Highly available control plane architectures and defined SLAs are therefore essential for operations in the public sector.
• Transparency: Government agencies are accountable to regulatory authorities, audit offices, and, if necessary, the public. All cluster configurations, access rights, and changes must therefore be documented in a way that is accessible and understandable at all times.

Case Study: A City Government’s Digital Citizen Portal

A medium-sized city government runs its digital citizen portal—including online applications, document management, and internal line-of-business applications—on Kubernetes. The requirements: BSI Basic Protection, GDPR compliance, and ISO 27001 certification.

Key design decisions: Public-facing applications and internal business applications run in strictly separated namespaces. No pod from the publicly accessible portal namespace is allowed to communicate directly with internal administrative systems. In addition, all container images used are based exclusively on open-source components and are managed in a self-hosted, internal registry to minimize dependencies on external providers. Configuration changes to the cluster are possible exclusively via a GitOps process—each change is assigned to a ticket, an assignee, and a timestamp, making it fully auditable. All cluster logs are routed to a central logging system that automatically enforces statutory retention periods and can be evaluated at any time for external audits by the Court of Auditors.

Best Practices for Kubernetes in Government Agencies

Private or Sovereign Cloud

Many government agencies rely on:

• On-Premises Kubernetes
• Private Clouds
• Sovereign Cloud Concepts

This ensures that data sovereignty is maintained.

Strong Governance Structures

Kubernetes requires clear organizational rules.

Key Areas:

• Role models
• Security Guidelines
• Auditing
• Approval Processes
• Compliance Controls

Long-term maintainability

Government systems often have to be operated for many years.

Therefore, the following points are important:

• standardized platforms
• documented processes
• automated updates
• Lifecycle management

What all three industries have in common

Despite all the differences, there are cross-industry patterns that every regulated Kubernetes environment should follow.

A Namespace Strategy as a Foundation:

The namespace structure is not only an organizational decision but also a security decision. In regulated environments, a functional and regulatory separation is particularly recommended: workloads with different protection requirements—such as patient data, payment information, or publicly accessible services—should run in separate namespaces, each with its own RBAC policies, network policies, and resource quotas. This allows for targeted access restrictions, control over data flow between areas, and, in the event of an audit, clear evidence of which workloads are subject to which compliance requirements.

Immutable Infrastructure and Traceable Deployments:

In regulated environments, no one is allowed to manually intervene in running containers. All changes are managed via Git. GitOps tools such as ArgoCD or Flux ensure that the cluster state matches the repository and that every change can be traced back to a commit. This is not merely a best practice; it is explicitly required by many regulatory bodies.

Supply Chain Security:

Where does the container image currently running in your cluster come from? In regulated environments, this is not a rhetorical question. Image signing (e.g., with Cosign/Sigstore), a Software Bill of Materials (SBOM), and automated vulnerability scanning aren’t just extras—they’re the foundation of a verifiable level of security.

Centralized Logging and SIEM Integration:

Kubernetes-native audit logs are a good start. In regulated environments, however, these logs must be fed into a central SIEM, where they are retained for a period of 6 to 12 months or longer and analyzed regularly. Tools such as Prometheus and Grafana assist with operational monitoring. For compliance-related logging, however, a well-thought-out aggregation and archiving strategy is also required.

The question regarding operations is: Do it yourself or use a managed service?

In a regulated industry, the question often arises: Should we run Kubernetes ourselves or use a managed service?

“Self-management” means full control, but also full responsibility. CVE patches, Kubernetes upgrades, backup strategies, node hardening: That’s a full-time job—even for experienced teams.

A managed Kubernetes service takes some of this responsibility off your hands—but only if the provider also meets the regulatory requirements. Relevant questions to ask a potential provider include:

• Where are the data centers located? (Germany/EU)
• What certifications are in place? (ISO 27001, C5, BSI)
• How are Kubernetes upgrades performed, and who notifies whom?
• Is there a documented shared-responsibility matrix?
• Can I perform a full audit of my cluster?

NWS operates NETWAYS Managed Kubernetes® exclusively in German data centers; it is ISO-certified and GDPR-compliant. Customers retain full control over their deployments, while NWS manages the cluster infrastructure, updates, and availability.

Advantages:

• automated updates
• built-in security features
• lower operating costs
• faster scaling

Conclusion

Using Kubernetes in regulated industries is not a contradiction, but it does require more than traditional setups. Whether it’s patient data, payment information, or government data, the requirements for traceability, data sovereignty, and security can be met with Kubernetes if the right decisions are made from the start.

A namespace strategy, RBAC, audit logging, supply chain security, and a provider that understands the regulatory framework are the building blocks of a cluster that not only runs but is also auditable. The sooner these foundations are laid, the less painful the first audit will be.

In which industry do you use Kubernetes, and which compliance requirement poses the greatest challenge for you? Leave a comment below or contact us directly. We understand the pitfalls of regulated environments from real-world experience.