Category: Security

IT Baseline Protection in the Cloud: Shared Responsibility in Practice

Resilience, Security 22nd Aug 2026 Martin-Peter Lambert
IT Baseline Protection in the Cloud: Shared Responsibility in Practice

IT Baseline Protection (IT-Grundschutz) is not limited to on-premises environments. Its principles are universal, but implementation in the cloud requires a new way of thinking. This article is the cloud-specific companion to our guide on ISO 27001 based on IT Baseline Protection.

IT Baseline Protection Meets the Cloud

The Shared Responsibility Model is key. Who is responsible for what? This question must be answered clearly. For the public sector, cloud migration means reinterpreting IT Baseline Protection: the building blocks do not change, but the way the requirements are met does. Automation and cloud-native tools play a central role.

Two stacked layers representing cloud provider and customer responsibility

The Shared Responsibility Model in Detail

  • Cloud Provider (e.g., Azure, AWS, GCP): Responsible for the security of the cloud. This includes the physical security of data centres, the security of the virtualisation layer, and the basic infrastructure.
  • Customer (Authority): Responsible for security in the cloud. This includes service configuration, identity and access management, data protection, and operating system patching.

The BSI-compliant cloud security concept documents this demarcation — and it is exactly the demarcation that BSI C5 calls the corresponding user-side criteria.

Implementing Baseline Protection Building Blocks in the Cloud

OPS.1.1.5: Logging

  • Azure: Azure Monitor, Log Analytics, Microsoft Sentinel
  • GCP: Cloud Logging, Cloud Monitoring, Google Security Operations (Chronicle)
  • Implementation: Enable logging for all services. Define retention periods. Automate analysis.

CON.1: Cryptography

  • Azure: Azure Key Vault, Always Encrypted, Transparent Data Encryption
  • GCP: Cloud Key Management Service, Confidential Computing
  • Implementation: Enforce data-in-transit and data-at-rest encryption. Centralise key management — see BYOK vs. HYOK.

ORP.4: Identity and Access Management

  • Azure: Entra ID, Conditional Access, Privileged Identity Management (PIM)
  • GCP: Cloud Identity, Identity-Aware Proxy (IAP), IAM Conditions
  • Implementation: Apply Zero Trust principles. Enforce MFA. Implement least privilege — see Conditional Access and MFA.

NET.1.1: Network Architecture

  • Azure: Virtual Network, Network Security Groups, Azure Firewall
  • GCP: Virtual Private Cloud (VPC), Firewall Rules, Cloud Armor
  • Implementation: Use hub-and-spoke or VPC peering. Enforce network segmentation. Activate DDoS protection.

Quick Checklist: IT Baseline Protection in the Cloud

Baseline Protection Building BlockCloud Tool (Azure Example)Implemented?
ORP.4 (IAM)Entra ID, PIM☐
CON.1 (Crypto)Key Vault, TDE☐
OPS.1.1.5 (Logging)Log Analytics, Sentinel☐
NET.1.1 (Network)VNet, NSGs, Firewall☐
SYS.1.1 (Server)Azure Policy, Defender for Cloud☐
CON.8 (Secure Development)Azure DevOps / GitHub Advanced Security☐

To-Do List for Cloud Baseline Protection

  • Week 1: Understand and document the Shared Responsibility Model.
  • Week 2: Conduct a cloud-specific risk analysis.
  • Month 1: Create a mapping of Baseline Protection building blocks to cloud services.
  • Month 2: Build a landing zone with Baseline Protection configurations (Policy-as-Code).
  • Month 3: Centralise logging and monitoring.
  • Ongoing: Monitor compliance status with cloud tools (e.g., Defender for Cloud).

The Role of BSI C5

BSI C5 and IT Baseline Protection are complementary. BSI C5 is a requirements catalogue specifically for cloud services. Many C5 requirements can be met directly with Baseline Protection measures. Anyone implementing IT Baseline Protection in the cloud is well on their way to BSI C5 compliance — and C5:2026 is now structurally aligned with ISO 27001:2022, which makes the mapping even more direct.

The BSI-compliant cloud security concept should integrate both frameworks. It demonstrates how the requirements of C5 and Baseline Protection are met through technical and organisational measures in the cloud.

Insight42: Your Partner for Cloud Security

We translate IT Baseline Protection for the cloud. We build secure landing zones that incorporate ISO 27001 and BSI C5 requirements from the start, and ensure ongoing secure operations with managed services.

Make your cloud Baseline Protection-compliant. See NIS2 & Cloud Security Beratung (German) or contact us.

Conditional Access and MFA: Intelligent Access Control for the Public Sector

AI In The Public Sector, Security 22nd Aug 2026 Martin-Peter Lambert
Conditional Access and MFA: Intelligent Access Control for the Public Sector

Old access models are obsolete. Once authenticated, always trusted? Dangerous. Conditional Access changes the game: every access is evaluated, context is key. This article follows on from our guide to Entra ID migration for public authorities and shows how to design the policies that make Zero Trust real.

Rethinking Access Control

For the public sector this is a step change. Security becomes dynamic, user-friendliness is maintained, and a cloud-first administration becomes defensible in front of auditors.

What Conditional Access Does

Conditional Access is a policy framework that evaluates access in real time. Who? From where? With what device? To what? These questions are answered on every sign-in.

Based on the answers, decisions are made: allow access, block access, require MFA, or restrict the session.

Understanding the Signals

User and Group — Who is accessing? Administrators have different rules than standard users. Externals different from internals.

Location — Where is the access coming from? Known networks are more trustworthy. Unknown countries are blocked.

Device — Is the device managed? Is it compliant? Unknown devices require additional verification.

Application — Which app is being accessed? Sensitive applications need stronger protection.

Risk — Entra ID automatically assesses sign-in and user risk. Unusual behaviour is detected. Compromised accounts are locked.

Quick Checklist: Conditional Access Policies

PolicyGoalAction
MFA for AdminsProtect privileged accountsEnforce MFA
Blocked CountriesStop attacks from high-risk regionsBlock access
Compliant DevicesAllow only secure devicesRequire compliance
Block Legacy AuthPrevent insecure protocolsBlock
Session TimeoutReduce risk during inactivityLimit session
App ProtectionProtect sensitive appsRequire MFA + Compliance

To-Do List for Conditional Access

  • Day 1: Activate report-only mode.
  • Week 1: Define baseline policies.
  • Week 2: Enforce MFA for all admins.
  • Week 3: Block legacy authentication.
  • Month 1: Introduce device compliance.
  • Month 2: Implement location-based policies.
  • Month 3: Implement risk-based policies.

Comparing MFA Methods

Not all MFA methods are equal. Some are more secure, others more user-friendly. The right choice depends on the context.

Microsoft Authenticator — Push notifications are simple. Number matching increases security. Passwordless login is possible.

FIDO2 Security Keys / Passkeys — Hardware-based and phishing-resistant. Ideal for high-security environments and administrators. Slightly higher cost.

SMS and Phone — Easy to implement, but less secure. Recommended only as a fallback.

Windows Hello for Business — On-device biometrics. Very user-friendly. Requires compatible hardware.

Meeting Compliance Requirements

BSI C5 demands strong authentication; Conditional Access delivers it. ISO 27001 based on IT-Grundschutz requires documented access control; Conditional Access logs every decision. NIS2 recommends Zero Trust; Conditional Access is a core component and supports the Data Protection Impact Assessment for cloud services.

Integration with Other Services

Conditional Access does not stand alone. It integrates with Microsoft Defender, uses Intune for device compliance, and connects to a SIEM (e.g., Microsoft Sentinel) for monitoring. A well-designed Azure Landing Zone includes the Conditional Access baseline from day one, and managed services keep the policies monitored.

Insight42 Conditional Access Services

We design Conditional Access strategies tailored for public authorities — compliant with BSI C5 and IT-Grundschutz, and user-friendly. From analysis to implementation and managed operations.

Control access intelligently. See NIS2 & Cloud Security Beratung (German) or contact us.

GDPR-Compliant Cloud Usage: Technical and Organisational Measures (TOMs) in Azure and GCP

Resilience, Security 22nd Aug 2026 Martin-Peter Lambert
GDPR-Compliant Cloud Usage: Technical and Organisational Measures (TOMs) in Azure and GCP

Article 32 of the GDPR calls for “appropriate technical and organisational measures” (TOMs) to ensure a level of security appropriate to the risk. But what does this mean in practice in the cloud? How do you translate legal requirements into technical configurations in Azure or GCP? This article is the practical follow-up to our guide to the Data Protection Impact Assessment for the cloud.

From Requirement to Technology

This article shows how to practically implement the abstract requirements of the GDPR using the native tools of the major cloud platforms. The cloud provider only supplies the tools; the authority, as the controller, is responsible for their correct use — the same shared-responsibility logic that applies to BSI C5.

A grid of six icons representing GDPR technical control categories

Mapping GDPR Requirements to Cloud Services

1. Pseudonymisation and Encryption (Art. 32(1)(a))

Goal: Make data unreadable to unauthorised persons.

  • Azure — Encryption at Rest: Transparent Data Encryption (TDE) for databases, Storage Service Encryption for storage accounts.
  • Azure — Encryption in Transit: Enforce TLS 1.2+ for all connections.
  • Azure — Key Management: Azure Key Vault for secure storage and management of keys (Bring Your Own Key – BYOK possible; Managed HSM for HYOK).
  • GCP — Encryption at Rest: Enabled by default for all services.
  • GCP — Encryption in Transit: Default for all connections.
  • GCP — Key Management: Cloud Key Management Service (Cloud KMS), also with BYOK and External Key Manager options.

For the choice between BYOK and HYOK see Cloud Key Management: BYOK vs. HYOK.

2. Confidentiality and Integrity (Art. 32(1)(b))

Goal: Ensure that only authorised persons can access data and that it cannot be altered unnoticed.

  • Azure — Access Control: Entra ID with Conditional Access and MFA, Privileged Identity Management (PIM) for admin rights.
  • Azure — Network Security: Network Security Groups (NSGs) and Azure Firewall for segmentation.
  • GCP — Access Control: Cloud IAM with Conditions, Identity-Aware Proxy (IAP) for Zero Trust access.
  • GCP — Network Security: VPC Firewall Rules and Cloud Armor.

3. Availability and Resilience (Art. 32(1)(b))

Goal: Ensure that systems function even in the event of disruptions or attacks.

  • Azure — High Availability: Use of Availability Zones and Availability Sets.
  • Azure — Scalability: Virtual Machine Scale Sets, App Service Plans.
  • GCP — High Availability: Distribution of instances across multiple zones.
  • GCP — Scalability: Managed Instance Groups (MIGs).

4. Recoverability (Art. 32(1)(c))

Goal: Be able to quickly restore data and systems after an incident.

  • Azure: Azure Backup for backing up VMs, databases, and file shares. Azure Site Recovery for disaster recovery.
  • GCP: Backup and DR Service, Snapshots for Persistent Disks.

5. Regular Testing and Evaluation (Art. 32(1)(d))

Goal: Continuously verify the effectiveness of the TOMs.

  • Azure: Microsoft Defender for Cloud for monitoring security configuration and detecting threats. Azure Policy for enforcing compliance rules.
  • GCP: Security Command Center for centralised vulnerability and compliance management.

Quick Checklist: Important TOMs in the Cloud

TOM CategoryMeasureImplemented?
EncryptionData-at-Rest & Data-in-Transit fully active☐
AccessMFA for all administrative and privileged accounts☐
NetworkStrict segmentation and firewall rules☐
BackupRegular, tested backups of all critical systems☐
MonitoringContinuous monitoring of security configuration☐
PatchingTimely application of security updates☐

TOMs as Part of the Security Concept

The defined TOMs are a central component of the security concept according to BSI C5 or IT Baseline Protection. They demonstrate how information security objectives are technically implemented. Good documentation of the TOMs is therefore essential not only for GDPR but also for audits according to BSI C5, ISO 27001 or NIS2.

Cloud consulting for public authorities helps to select and implement the right TOMs for your specific requirements. It is not about doing everything that is technically possible, but what is appropriate for the risk.

Insight42: We Make Your Cloud GDPR-Compliant

We translate the GDPR into the language of the cloud. We configure Azure, AWS and GCP to meet the requirements for technical and organisational measures — securely, documented, and auditable. Our managed cloud operations include the continuous monitoring and optimisation of your TOMs, so that your data protection level remains high even as threats and technologies change.

Implement data protection technically. See NIS2 & Cloud Security Beratung (German) or contact us.

Cloud Key Management: BYOK vs. HYOK in Azure and GCP

Security, Sovereignty Series 22nd Aug 2026 Martin-Peter Lambert
Cloud Key Management: BYOK vs. HYOK in Azure and GCP

Encryption is the foundation of cloud security. But who controls the keys? By default, the cloud provider does. This is convenient, but often not sufficient for sensitive government or regulated data — because whoever controls the key can decrypt the data, and that includes the provider itself and potentially foreign authorities. This article is the practical companion to our guide on digital sovereignty for the public sector and compares the two models that put key control back in your hands.

Comparison of key management models BYOK and HYOK

Whoever Holds the Key, Holds the Power

The solution: take control of your keys yourself. The two most important models for this are Bring Your Own Key (BYOK) and Hold Your Own Key (HYOK), also known as external key management.

Bring Your Own Key (BYOK)

The principle: You create your keys in your own environment (e.g., with an on-premises Hardware Security Module – HSM) and securely import them into the cloud provider’s key management system (e.g., Azure Key Vault, GCP Cloud KMS).

Advantages:

  • Full control over the creation and lifecycle of the key.
  • The key can be revoked (deleted) at any time, rendering the data unusable.
  • Relatively simple integration with most cloud services.

Disadvantages:

  • The key is physically located in the provider’s cloud. Access by the provider, though unlikely, is not 100% technically impossible.

Provider services: Azure Key Vault (Premium tier), GCP Cloud KMS with imported keys, AWS KMS with imported key material.

Hold Your Own Key (HYOK) / External Key Management

The principle: The key never leaves your own controlled environment. The cloud services send the data to be encrypted or decrypted to your external key manager. The key itself is never transferred.

Advantages:

  • Maximum control and sovereignty. The key is physically and logically separate from the cloud.
  • Access by the cloud provider or third parties is technically impossible without your key manager.

Disadvantages:

  • Higher complexity and potentially higher latency.
  • Requires a highly available key management infrastructure of your own.
  • Not supported by all cloud services.

Provider services: Azure Key Vault Managed HSM, GCP External Key Manager (EKM), AWS KMS External Key Store (XKS).

Quick Checklist: Which Model is Right?

CriterionBYOKHYOK/EKM
Sovereignty LevelHighVery High
ComplexityMediumHigh
PerformanceHighMedium
CostMediumHigh
Service CompatibilityBroadLimited
Recommendation forStandard for sensitive dataHighest protection needs (KRITIS, classified information)

To-Do List for Sovereign Key Management

  • Week 1: Analyse the protection needs of the data requiring key control.
  • Week 2: Evaluate the BYOK and HYOK offerings of the cloud providers in detail.
  • Month 1: Decide on a model (or a combination).
  • Month 2: Create a concept for the on-premises HSM infrastructure (if necessary).
  • Month 3: Configure the key management service in the cloud.
  • Month 4: Define processes for key lifecycle management (creation, rotation, deletion, emergency access).

Integration into the Security Architecture

External key management is not an isolated topic. It must be integrated into the overall BSI-compliant cloud security concept. It is a central measure for meeting the requirements of BSI C5, IT Baseline Protection, NIS2 and GDPR.

The processes surrounding key management must be clearly defined and documented. Who can create keys? Who approves their use? What happens in an emergency? IT Baseline Protection consulting helps to design these processes robustly.

Insight42: Cloud Key Management Expertise

We help you regain control over your keys and thus your data. We analyse your needs, compare the solutions, and implement the model that is right for you — whether it’s BYOK with Azure Key Vault or HYOK with external HSMs.

Lock your data securely. See Verschlüsselung & Key Management (German) or contact us.

Preparing for a BSI C5 Audit: Practical Tips for the Public Sector

Resilience, Security 22nd Aug 2026 Martin-Peter Lambert
Preparing for a BSI C5 Audit: Practical Tips for the Public Sector

You have decided on BSI C5. Implementation is underway. Now comes the audit. How do you prepare? What can you expect? This article is the practical follow-up to our BSI C5 Cloud Certification guide and walks through documentation, evidence, typical findings and interview preparation.

The Audit is Approaching

BSI C5 audits are thorough. Auditors want to see evidence — not just documents, but also established practices. Since April 2026 the reference catalogue is C5:2026; if your attestation period starts after mid-2027, prepare against the new criteria (container management, tenant isolation, confidential computing, post-quantum cryptography, supply chain).

Documentation is Everything

No attestation without documentation. Auditors can only audit what is documented. Every control needs evidence. Every process needs a description.

What must be documented:
Security policies and their approval, process descriptions with responsibilities, configuration standards and their implementation, employee training records, and logs as proof.

The Most Common Audit Findings

Preparation also means avoiding mistakes. These findings are common:

Incomplete Documentation

Controls exist but are not documented, or the documentation is outdated. Solution: Keep documentation current by automating evidence collection from your cloud platform, so reality and documentation stay in sync.

Missing Evidence

Processes are followed but not logged. Solution: Enable logging and recording.

Inconsistent Implementation

Policies exist but are not followed. Solution: Conduct regular internal audits.

Unclear Responsibilities

No one feels responsible. Solution: Create a RACI matrix.

Quick Checklist: Audit Preparation

DocumentContentCurrent?
ISMS ManualOverall Security Overview☐
Security PoliciesAll Policies☐
Risk AnalysisCurrent Assessment☐
Asset RegisterComplete Inventory☐
Access MatrixPermissions Documented☐
Incident LogIncidents Logged☐
Training RecordsAll Employees☐
Audit TrailChanges Traceable☐

To-Do List for Audit Readiness

  • 8 weeks prior: Fully review documentation.
  • 6 weeks prior: Conduct an internal pre-audit.
  • 4 weeks prior: Remediate findings.
  • 2 weeks prior: Compile evidence.
  • 1 week prior: Brief interview partners.
  • Audit Day: Stay calm, cooperate.
  • After Audit: Remediate findings promptly.

The BSI-Compliant Cloud Security Concept

The security concept is the centrepiece. It comprehensively describes your cloud security. Auditors will read it carefully.

Contents of the Security Concept:

Scope and demarcation of cloud use, risk analysis and assessment, technical and organisational measures, responsibilities and processes, and emergency and business continuity management.

IT baseline protection consulting helps with its creation. ISO 27001 based on IT-Grundschutz provides the structure. The result: an audit-proof document.

Mastering Interviews

Auditors conduct interviews. They want to understand how controls are put into practice. Brief every interview partner on their controls, the evidence that backs them and the process for exceptions — preparation is of the utmost importance.

Continuous Compliance

BSI C5 is not a one-time project; it is a continuous process. After the audit is before the audit — especially for a Type 2 attestation, where the controls must demonstrably work throughout the audit period.

Cloud managed services for authorities help with this through continuous monitoring, regular reviews, and automated compliance checks. Azure and GCP native tooling provides dashboards showing compliance status and alerts for deviations.

Insight42 Audit Support

We guide you through the audit: preparation, execution, and follow-up, with experienced consultants by your side. We create the BSI-compliant cloud security concept together with you and implement the technical controls that back it.

Pass your audit. See our BSI C5 Beratung (German) or contact us to book a C5 readiness call.

CrackArmor Explained: When Linux’s Trusted Guard Dog Hands Over the Keys

Security, Sovereignty Series 21st Mar 2026 Martin-Peter Lambert
CrackArmor Explained: When Linux’s Trusted Guard Dog Hands Over the Keys

Understanding the AppArmor Vulnerability that Allows Any Local User to Break System Isolation and Gain Full Root Access.

Since 2017, a silent flaw has been lurking within one of the most trusted security components of the Linux ecosystem. Dubbed “CrackArmor” by the Qualys Threat Research Unit (TRU), this cluster of nine vulnerabilities targets AppArmor, the default Mandatory Access Control (MAC) system for major Linux distributions like Ubuntu, Debian, and SUSE. With over 12.6 million enterprise systems affected globally—spanning cloud environments, Kubernetes clusters, and edge devices—CrackArmor represents a fundamental breakdown in how we enforce system isolation. Here is a deep dive into the mechanics of the vulnerability, how it operates under the hood, and what its exploitation looks like in the worst-case scenario. In particular, we now face the challenge of understanding how this AppArmor vulnerability allows any local user to break system isolation and gain full root access.

The Core Issue: A “Confused Deputy”

At its heart, CrackArmor is not a failure of the Mandatory Access Control concept, but rather an implementation flaw that creates a classic “confused deputy” scenario, resulting in unprecedented system isolation bypass—any local user can gain root access when exploiting this AppArmor vulnerability.

Imagine a secure facility where a low-level employee (the unprivileged user) is not allowed into the vault. However, the employee tricks the facility manager (a privileged process) into opening the vault on their behalf. Because the vault trusts the manager’s keys, the door opens. To illustrate, it is similar to understanding how AppArmor vulnerabilities grant local users power to break system isolation and obtain root access.

In the Linux kernel, unprivileged local attackers can exploit trusted applications—like sudo or the Postfix mail server—to interact with highly sensitive AppArmor pseudo-files located at /sys/kernel/security/apparmor/ (specifically the .load, .replace, and .remove files). By manipulating these privileged applications, an attacker can bypass user-namespace restrictions, manipulate security profiles, and force the kernel to execute unauthorized commands. Ultimately, this scenario exposes a vulnerability in AppArmor that lets local users break system isolation and achieve root access.

Technical Deep Dive: How the Exploit Chain Works

The CrackArmor vulnerabilities (partially tracked as CVE-2026-23268 and CVE-2026-23269) grant unprivileged users the power to rewrite the rules of the system’s security boundary. This enables several devastating attack vectors, and highlights why understanding how the AppArmor vulnerability allows any local user to break system isolation and reach full root access is crucial.

Attack VectorDescription
Policy ManipulationAttackers can dynamically load or remove AppArmor profiles. For example, they could remove the protective profiles for rsyslogd or cupsd, exposing them to remote attacks, or load a “deny-all” profile for sshd, instantly locking legitimate administrators out of remote SSH access.
Namespace BreakoutsBy loading a “userns” profile for standard binaries (like /usr/bin/time), an attacker can spawn fully capable user namespaces. This effectively neutralizes Ubuntu’s user-namespace restrictions, allowing an attacker to break out of isolated containers. The exploit chain centers on AppArmor vulnerabilities that enable any local user to break system isolation and escalate privileges to root.
Kernel-Space ExploitationA use-after-free vulnerability in the aa_loaddata kernel routine allows attackers to reallocate a freed memory page as a page table that maps to /etc/passwd. By doing this, the attacker can overwrite the root password line directly in memory and seamlessly switch to a full root shell. To further clarify, this kernel-space exploitation ties directly to understanding the AppArmor vulnerability which enables breaking system isolation and full root access by any local user.

The Worst-Case Scenario

If CrackArmor is successfully weaponized by a malicious actor, the blast radius is catastrophic. The worst-case scenario manifests in two primary ways: Total System Takeover and Catastrophic Denial of Service (DoS). Indeed, understanding the AppArmor vulnerability that allows any local user to break system isolation and gain full root access is vital for grasping the scope of these risks.

1. Complete Cloud and Container Collapse (Total Compromise)

In a modern infrastructure relying on Kubernetes or Docker, AppArmor serves as the foundational wall keeping containers isolated from one another and from the host OS. In a worst-case scenario, an attacker who gains a low-level, unprivileged foothold (e.g., via a compromised web app or a leaked low-privilege SSH key) can instantly break out of their containerized sandbox. This demonstrates a practical outcome from the AppArmor vulnerability: a local user can break system isolation and become root.

By executing the aa_loaddata use-after-free exploit, they achieve Local Privilege Escalation (LPE) to root. From there, they own the host kernel. They can read sensitive secrets from other containers, modify system binaries, tamper with credentials, or pivot laterally to infect the rest of the network. The zero-trust boundary evaporates instantly, another direct result of how AppArmor vulnerabilities let local users break isolation and gain root access.

2. Weaponized Kernel Panics (Denial of Service)

State-sponsored actors and ransomware gangs increasingly favor disruptive attacks. CrackArmor provides a literal “kill switch” for the Linux kernel. Thus, understanding this AppArmor vulnerability that lets any user break system isolation and reach root access is essential for defense planning.

AppArmor profiles can contain nested sub-profiles. CrackArmor allows an attacker to manipulate the kernel’s recursive removal routine (__remove_profile()). By feeding the system a deeply nested hierarchy of sub-profiles (e.g., 1024 levels deep), the kernel attempts to process them all at once. This triggers a recursive loop that completely exhausts the kernel stack (which is severely limited to roughly 16 KB on x86-64 architectures). The immediate result? A hard kernel panic and a forced system reboot, again associated with the impact of AppArmor flaws that allow local users to break isolation and gain root.

An attacker could script this to happen continuously on boot, permanently bricking critical cloud nodes, energy sector infrastructure, or healthcare databases without ever needing administrative credentials. Importantly, this highlights the consequences of understanding the AppArmor vulnerability that enables local users to break system isolation and access root privileges.

Conclusion and Mitigation

CrackArmor is a stark reminder that even the most deeply entrenched, default security controls are subject to fatal flaws. Patching alone is critical, but security teams must also re-evaluate their reliance on default configurations. In closing, it is crucial to understand the AppArmor vulnerability that allows local users to break system isolation and gain full root access, so new measures can be implemented.

Immediate Steps for Administrators:

  • Patch Instantly: Apply the vendor kernel updates (spanning kernels from v4.11 onward) immediately. This is not a vulnerability that can wait for the next maintenance window. Proactive patching is especially important given how AppArmor vulnerabilities let local users break isolation and become root.
  • Monitor Integrity: Implement strict file integrity monitoring on the /sys/kernel/security/apparmor/ directory to catch unauthorized .load or .replace modifications, which serve as the primary indicators of an active CrackArmor exploit. In short, monitoring is a mitigation strategy to address the risk from AppArmor vulnerabilities where system isolation can be broken and root access gained by any user.
  • Scan Assets: Utilize vulnerability scanners to map out all instances of Ubuntu, Debian, and SUSE running vulnerable kernel versions across all edge, cloud, and containerized environments. This is vital due to the potential for any local user to break system isolation and reach root through the AppArmor flaw.

Sovereign Cloud Germany: Digital Sovereignty for the Public Sector

Azure CAF & Cloud Migration, Resilience, Security 25th Feb 2026 Martin-Peter Lambert
Sovereign Cloud Germany: Digital Sovereignty for the Public Sector

Updated August 2026: the sovereign-cloud market in Germany has moved. The AWS European Sovereign Cloud has been live since January 2026 (Brandenburg region, EU-only operating entity), Delos Cloud brings the Microsoft stack under German operator control for the public sector, STACKIT and IONOS offer European-controlled platforms, the Deutsche Verwaltungscloud (DVC) has become a product of the IT-Planungsrat, and the BSI published C5:2026 in April. The three pillars below are unchanged — the options for implementing them are much broader.

What Does Digital Sovereignty Mean?

Digital sovereignty is the ability to control one’s own IT infrastructure and data with self-determination. For the public sector, this is not a luxury but a necessity. It is about controlling citizen data, independence from individual providers, and compliance with German and European legal norms (GDPR, Schrems II).

A sovereign cloud in Germany provides the technical and organisational framework to ensure this control. It combines the innovative power of global hyperscalers (like Azure, AWS and GCP) or European platforms with the strict requirements of German and European law.

The Three Pillars of Digital Sovereignty

Sovereign cloud architecture: data residency, control and transparency, key management

1. Data Residency

  • What it is: The guarantee that data and metadata are stored and processed exclusively within a defined geographical area (e.g., Germany or the EU).
  • Why it matters: Prevents access by foreign authorities based on laws like the US CLOUD Act. Ensures compliance with GDPR.
  • Implementation: Use of cloud regions in Germany (e.g., Frankfurt, Berlin, Brandenburg). Contractual assurances from the provider. Note that residency alone does not prevent access by the operator or by third-country law — see pillars 2 and 3.

2. Control & Transparency

  • What it is: The ability to seamlessly control and log access to data and systems, including access by the cloud provider itself.
  • Why it matters: Creates trust. Enables proof of compliance (BSI C5, GDPR, NIS2).
  • Implementation: Strict access controls (Zero Trust, MFA), comprehensive logging, EU-only operating staff, use of external control bodies (e.g., data trustees).

3. Key Management

  • What it is: Control over the cryptographic keys used to encrypt data. Whoever holds the key, controls the data.
  • Why it matters: It is the ultimate lever for data sovereignty. Even if a provider could access the encrypted data, they cannot read it without the key.
  • Implementation: Bring Your Own Key (BYOK) or Hold Your Own Key (HYOK), where the keys remain within your own infrastructure. We compare both models in Cloud Key Management: BYOK vs. HYOK in Azure and GCP.

Quick Checklist: Digital Sovereignty

PillarKey QuestionImplemented?
Data ResidencyIs all data guaranteed to be in Germany/EU?☐
ControlDo we have full control over all access?☐
TransparencyIs all access logged completely?☐
Key ManagementDo we control the cryptographic keys?☐
ExitCould we move to another provider, and have we tested it?☐
ComplianceAre the requirements of GDPR, BSI C5, NIS2 etc. met?☐

To-Do List for a Sovereign Cloud Strategy

  1. Immediately: Classify the protection needs of the data.
  2. Week 1: Define the requirements for digital sovereignty per workload (residency, operational control, legal immunity).
  3. Week 2: Evaluate the market for sovereign cloud offerings (AWS European Sovereign Cloud, Delos Cloud, STACKIT, IONOS, T-Systems, Azure and GCP sovereign controls).
  4. Month 1: Establish a strategy for data residency and key management.
  5. Month 2: Adapt the BSI-compliant cloud security concept accordingly.
  6. Month 3: Start a pilot project in a sovereign cloud environment.

Sovereign Offerings: Hyperscalers and European Platforms

The major providers have recognised the need and offer dedicated solutions — and European platforms have matured:

  • AWS European Sovereign Cloud: A physically and logically separate AWS cloud in the EU, operated by an EU entity with EU-resident staff, live since January 2026.
  • Microsoft Cloud for Sovereignty / Delos Cloud: Data residency and enhanced controls on Azure; Delos Cloud delivers the Microsoft stack under German operator control for the public administration.
  • Google Cloud Sovereign Solutions: Similar guarantees for data location and control, often in partnership with local providers (e.g., T-Systems).
  • STACKIT, IONOS, Open Telekom Cloud: European-owned and -operated platforms, increasingly used for public-sector and KRITIS workloads.

These offerings are an important step but require careful examination of operator model, service parity, key model, exit capability and cost. Cloud consulting for public authorities helps to validate the providers’ promises and find the right solution for your needs.

The Role of BSI C5 and IT Baseline Protection

Digital sovereignty and compliance go hand in hand. Being BSI C5 compliant is a basic requirement for a sovereign cloud. The controls in the C5 catalogue cover many aspects of sovereignty, especially in the areas of transparency and operational security — and C5:2026 adds tenant isolation, confidential computing and supply-chain criteria.

IT Baseline Protection consulting helps to integrate the BSI’s requirements into the cloud architecture. An ISO 27001 certification based on IT Baseline Protection demonstrates the effectiveness of the implemented measures.

Insight42: Your Guide to Digital Sovereignty

The path to a sovereign cloud is complex. We navigate you safely through the technological, legal, and organisational challenges. We know the offerings, the pitfalls, and the success factors.

We help you develop a strategy tailored to your specific protection needs — from data residency to external key management. Secure, BSI C5 compliant, and future-proof.

Take control. See our Souveräne Cloud Beratung (German) or contact us to request a Sovereign Cloud Assessment.

Data Protection Impact Assessment (DPIA) for the Cloud: A Guide for Public Authorities

Resilience, Security 23rd Feb 2026 Martin-Peter Lambert
Data Protection Impact Assessment (DPIA) for the Cloud: A Guide for Public Authorities

Why a DPIA is Mandatory for Cloud Projects

The cloud offers enormous opportunities, but it also poses risks to data protection. The General Data Protection Regulation (GDPR) therefore requires a Data Protection Impact Assessment (DPIA) when there is a high risk to the rights and freedoms of natural persons. For the public sector, which works with sensitive citizen data, this is almost always the case for cloud projects.

A DPIA is not an obstacle; it is a tool for risk minimisation. It forces a systematic engagement with data protection and creates legal certainty for your cloud project. A missing DPIA can lead to significant fines and the halting of the project.

When Exactly is a DPIA Required?

Article 35 of the GDPR is clear. A DPIA is required, in particular, for:

  • Large-scale processing of special categories of data (e.g., health data).
  • Systematic and extensive evaluation of personal aspects (profiling).
  • Large-scale monitoring of publicly accessible areas.

The German Data Protection Conference (DSK) has published a positive list of processing activities for which a DPIA is generally required. The use of cloud services for specialised procedures with large amounts of data often falls into this category.

A four step staircase illustrating the DPIA process

The 4 Steps of a Data Protection Impact Assessment

A DPIA follows a structured process. It is not a one-time document but a living process.

Step 1: Systematic Description

  • What? What data is being processed?
  • Why? What is the purpose of the processing?
  • Who? Who are the parties involved (controller, processor)?
  • How? What technologies and processes are being used?

Step 2: Assessment of Necessity and Proportionality

Is the processing truly necessary for the purpose? Are there milder, more data-minimising alternatives? The legal basis must be clear.

Step 3: Risk Assessment

What are the risks to the data subjects (citizens)? (e.g., unauthorised access, data loss, discrimination). The likelihood of occurrence and the severity of the potential harm are assessed.

Step 4: Remedial Measures

What technical and organisational measures (TOMs) will be taken to minimise the risks? This includes encryption, access controls, and contractual arrangements with the cloud provider. We show how to implement them in Azure and GCP in GDPR-Compliant Cloud Usage: TOMs in Azure and GCP.

Quick Checklist: DPIA for the Cloud

StepKey QuestionDone?
1. DescriptionIs the processing completely described?☐
2. NecessityIs the legal basis clear and the processing proportionate?☐
3. Risk AssessmentAre the risks to data subjects identified and assessed?☐
4. MeasuresAre effective remedial measures defined?☐
5. DocumentationIs the entire DPIA comprehensibly documented?☐
6. ConsultationMust the Data Protection Officer or the supervisory authority be consulted?☐

To-Do List for the DPIA

  1. Immediately: Clarify whether a DPIA is mandatory for the cloud project.
  2. Week 1: Appoint a responsible team for the DPIA.
  3. Week 2: Involve the Data Protection Officer at an early stage.
  4. Month 1: Begin the systematic description of the processing.
  5. Month 2: Conduct the risk assessment.
  6. Month 3: Define remedial measures with the cloud service provider and the IT security team.
  7. Ongoing: Update the DPIA whenever the system changes.

The Challenge: Third-Country Transfers

Since the Schrems II ruling, data transfers to the US and other third countries have become complex. Cloud providers like Microsoft (Azure), Amazon (AWS) and Google (GCP) are US companies. A DPIA must explicitly assess this risk — including the possibility of access under the US CLOUD Act regardless of where the data centre is located.

Remedial measures for this include:

  • Standard Contractual Clauses (SCCs): The standard mechanism, but often not sufficient on its own.
  • Additional TOMs: Strong encryption (ideally with your own keys – BYOK/HYOK), pseudonymisation, anonymisation.
  • Sovereign Cloud Options: Use of EU-operated platforms and contractual assurances — see Sovereign Cloud Germany.

Insight42: Your Partner for the Cloud DPIA

A DPIA for cloud services requires legal, technical, and procedural knowledge. We connect these worlds. Our Data Protection Impact Assessment consulting is practice-oriented and tailored to the public sector.

We help you identify risks, define effective measures, and design your cloud projects to be legally compliant, in line with BSI C5 and IT Baseline Protection.

Make your data protection future-proof. See NIS2 & Cloud Security Beratung (German) or contact us.

BSI C5 Cloud Certification: A Guide for Public Authorities

Resilience, Security, Sovereignty Series 20th Feb 2026 Martin-Peter Lambert
BSI C5 Cloud Certification: A Guide for Public Authorities

Updated August 2026: the BSI published C5:2026 in April 2026. It adds criteria for container management, tenant isolation, confidential computing, post-quantum cryptography and supply-chain security, and aligns the catalogue with ISO 27001:2022, NIS2 and the European EUCS scheme. Attestations with a reference date or audit period starting after mid-2027 will be measured against C5:2026 — plan the transition now.

What is BSI C5?

BSI C5 (Cloud Computing Compliance Criteria Catalogue) is the German standard for cloud security, developed by the Federal Office for Information Security (BSI). It defines minimum requirements for cloud services and is effectively mandatory for the public sector, for health data under § 393 SGB V, and increasingly for any organisation that has to evaluate cloud suppliers under NIS2.

Is cloud migration for the public sector possible without BSI C5? It’s risky. Tenders for cloud migration usually demand it, and the procurement process for cloud service providers verifies the attestation. Strictly speaking there is no “C5 certification” — C5 is attested by an auditor under IDW PS 951 / ISAE 3000. The market uses both terms; in tenders, ask for a “C5 Type 2 attestation”.

The Structure of BSI C5

BSI C5 comprises 17 requirement domains, from organisation to incident management. Each domain contains specific controls that must be demonstrated.

The 17 Domains at a Glance:

Information Security Organization, Security Policies, Human Resources, Asset Management, Physical Security, Operations Security, Identity and Access Management, Cryptography, Communication Security, Portability and Interoperability, Procurement and Development, Supplier Relationships, Security Incident Management, Compliance, Data Protection, Product Security, Interoperability.

Type 1 vs. Type 2 Attestation

BSI C5 has two attestation types, and the difference is important.

Type 1 Attestation

This assesses the appropriateness of the controls at a specific point in time.
– Are the controls designed?
– Are they implemented?

Type 2 Attestation

This assesses the effectiveness of the controls over a period of at least six months.
– Do the controls work?
– Are they being followed?

For public authorities, a Type 2 attestation is usually required. It offers more assurance and demonstrates continuous compliance.

Quick Checklist: BSI C5 Readiness

DomainCheckpointStatus
OrganizationISMS Established☐
PoliciesSecurity Policies Documented☐
PersonnelAwareness Training Conducted☐
AssetsInventory Complete☐
AccessIAM Implemented☐
CryptographyEncryption Active☐
LoggingLogging Enabled☐
IncidentProcess Defined☐

To-Do List for BSI C5 Attestation

  1. Month 1: Conduct a gap analysis.
  2. Month 2: Create an action plan.
  3. Months 3-6: Implement controls.
  4. Month 7: Perform an internal audit.
  5. Month 8: Conduct an external pre-audit.
  6. Months 9-10: Undergo the Type 1 audit.
  7. Months 11-16: Operational phase.
  8. Month 17: Undergo the Type 2 audit.

The Path to Attestation

Becoming BSI C5 compliant is a project. It requires planning, resources, and expertise.

Step 1: Gap Analysis

Where do you stand today? Which controls are missing? IT baseline protection consulting helps with the assessment. The gap analysis shows the way forward.

Step 2: Action Planning

  • What measures are necessary?
  • In what order? With what budget?
  • Who owns each measure, and when is it due?

Step 3: Implementation

  • Controls are introduced
  • Processes are established
  • Documentation is created
  • The BSI-compliant cloud security concept is developed

Step 4: Audit

An auditor conducts the review. The controls are tested. Evidence is collected. The attestation is issued. We cover this phase in detail in Preparing for a BSI C5 Audit: Practical Tips for the Public Sector.

Cloud Providers and BSI C5

Major cloud providers like Azure, GCP, and AWS hold BSI C5 attestations. But that’s not enough to claim that using them makes you compliant — quite the opposite. Because of the shared responsibility model, you still need to implement the corresponding user-side controls and operate them correctly. Only then can you be C5-compliant.

Azure migration and GCP migration must consider BSI C5. An Azure Landing Zone and a GCP Landing Zone should incorporate BSI C5 controls from day one. The Cloud Adoption Framework helps with this.

Insight42 BSI C5 Services

We guide public authorities and cloud providers to BSI C5 compliance, from gap analysis to the audit. We deliver the BSI-compliant cloud security concept and its technical implementation from a single source — with experience in BSI C5 and IT-Grundschutz projects for the public sector, and continuous-compliance managed services after the attestation.

Become BSI C5 compliant. See our BSI C5 Beratung (German) or contact us to book a C5 readiness call.

ISO 27001 Based on IT-Grundschutz: The Royal Road for Public Authorities

Resilience, Security 15th Feb 2026 Martin-Peter Lambert
ISO 27001 Based on IT-Grundschutz: The Royal Road for Public Authorities

Why IT Baseline Protection is the Standard for Public Authorities

The BSI’s IT Baseline Protection (IT-Grundschutz) is more than a recommendation; it is the de facto standard for information security in German public administration. It offers concrete measures, field-tested building blocks, and a clear methodology, which makes it incredibly valuable.

An ISO 27001 certification is internationally recognised and demonstrates a functioning Information Security Management System (ISMS). Combining these two worlds is ideal: the specific guidelines of IT Baseline Protection fulfil the abstract requirements of ISO 27001.

The Synergy of IT Baseline Protection and ISO 27001

ISO 27001 requires an ISMS but does not specify how to implement it. IT Baseline Protection provides exactly that: a detailed guide. Those who implement IT Baseline Protection have already done most of the work for an ISO 27001 certification.

The advantages of this combination:

  • Concrete and Field-Tested: IT Baseline Protection offers ready-made building blocks.
  • BSI-Recognised: The methodology is well-established within the German public sector.
  • Efficient: It avoids duplication of effort.
  • Internationally Recognised: The ISO 27001 certification builds trust.
A five step staircase leading to an ISO 27001 certification badge

The Path to Certification

Step 1: Structural Analysis — Which information, processes, and IT systems need protection? The structural analysis defines the scope of the ISMS.

Step 2: Protection Needs Assessment — How critical is the data? Normal, high, or very high? The protection needs assessment evaluates the requirements for confidentiality, integrity, and availability.

Step 3: Modelling According to IT Baseline Protection — The identified systems are mapped to the building blocks of the IT-Grundschutz Compendium. The result is a list of relevant requirements.

Step 4: Basic Security Check — This is a gap analysis. Which requirements are already implemented? Where are the gaps? The basic security check identifies the need for action.

Step 5: Implementation and Audit — The gaps are closed. The ISMS is put into practice. An external auditor verifies conformity and issues the ISO 27001 certificate.

Quick Checklist: ISO 27001 Based on IT Baseline Protection

PhaseTaskStatus
1. PreparationDefine Scope☐
2. AnalysisConduct Structural Analysis☐
3. AssessmentDetermine Protection Needs☐
4. ModellingMap IT Baseline Protection Building Blocks☐
5. Gap AnalysisPerform Basic Security Check☐
6. ImplementationExecute Action Plan☐
7. AuditCertification Audit☐

To-Do List for Project Managers

  1. Immediately: Secure management commitment.
  2. Week 1: Appoint an ISMS team.
  3. Week 2: Commission IT Baseline Protection consulting.
  4. Month 1: Start the structural analysis.
  5. Month 2: Complete the protection needs assessment.
  6. Quarter 2: Conduct the basic security check.
  7. Quarters 3-4: Implement measures.
  8. Next Year: Plan the certification audit.

IT Baseline Protection in the Cloud

The principles of IT Baseline Protection also apply in the cloud, but the implementation differs. Responsibility is shared. Cloud providers (Azure, AWS, GCP) deliver a secure foundation, while the authority is responsible for secure configuration and use (Shared Responsibility Model).

An ISO 27001 certification based on IT Baseline Protection for cloud workloads is possible. It requires a clear understanding of responsibilities, and BSI C5 requirements are integrated here. We map the building blocks to concrete cloud services in IT Baseline Protection in the Cloud: Shared Responsibility in Practice.

Insight42: Your Partner for IT Baseline Protection

We support ISO 27001 projects based on IT Baseline Protection for the public sector — from the initial analysis to successful certification and beyond, with managed services for continuous security and compliance.

Start on the secure path. See BSI C5 Beratung (German) or contact us.