# One Kafka Control Layer for DORA, GDPR and IT-Grundschutz ## Kafka is business-critical, but often off the radar A Kafka platform ingests, stores and processes data that is often critical in more than one sense: **business-critical** because it drives transactions, payments, fraud detection, order and logistics flows, grid and sensor telemetry, and the operational decisions built on them; **security-critical** because confidentiality, integrity and availability matter; and **regulatory-relevant** because PII or supervised business processes may be part of the stream. Surprisingly, it rarely shows up on the radar of the risk and compliance function. Partly a lack of awareness: warehouses and lakehouses take the attention because they are easier to picture (just a big database, the kind everyone is used to), while streaming gets waved off as *"just a pipe, and the data there is ephemeral"*. That could not be more wrong. Streaming, and Kafka in particular, is barely understood there; the specific risks are rarely mapped; and unlike databases or web applications, Kafka has **no established audit grid**: no broadly recognized best practices, no risk catalogue, not even a dedicated building block in IT-Grundschutz. The following regulations and frameworks bear on it directly, and across the DACH region they apply at the same time: - **DORA**, in force since 2025: demonstrable operational resilience for the financial sector. - **GDPR**, in force since 2018: data protection requirements that become technically challenging on Kafka, especially where personal data sits in immutable, replicated and long-retained logs. - **BSI IT-Grundschutz**: the de-facto information-security standard in the German-speaking region, the one supervisors, KRITIS (critical-infrastructure) operators and corporate procurement measure you against. Move regulated or high-risk data over Kafka in the DACH region and you often have to serve all three at once, usually across several clusters and environments. Spinning up a separate initiative for each is the expensive path, and it hides the real opportunity: these regulations and frameworks overlap heavily. The same set of controls sits at the center of all of them. Once you see that, the job stops being parallel silos and becomes one control landscape that serves every framework at once. This article is not a legal opinion or a certification checklist. It is a technical control-layer view: how Kafka governance, encryption, access control, audit, lineage and resilience can be organized so that DORA, GDPR and IT-Grundschutz can be addressed from one consistent evidence base. The regulatory interpretation, data classification and final control assessment remain with the organization. This article covers three things: - What they technically demand - Why Kafka does not meet those requirements out of the box - How the same controls can be built once and used for all three ## The Tech: DORA, GDPR, IT-Grundschutz ### DORA In force since January 2025, DORA covers financial entities and their critical ICT (Information and Communication Technology) third-party service providers. It rests on five pillars: - ICT risk management - handling and reporting of ICT-related incidents - testing of digital operational resilience - management of ICT third-party risk - information sharing What the organization must answer now is not "does the system work?" but "does it stay manageable, demonstrable and reportable under stress?". ### GDPR It introduces data protection, processing and privacy requirements that are especially relevant for event streaming: - Art. 5, the core principles, including data minimization and accountability - Art. 17, the right to erasure, the sticking point where personal data is written into long-retained, replicated logs - Art. 25, data protection by design - Art. 30, the record of processing activities - Art. 32, security of processing, which names encryption and pseudonymization explicitly - Art. 33, the 72-hour deadline to report a personal data breach - Chapter V, transfers to third countries ### BSI IT-Grundschutz It supplies the methodology and a Compendium of building blocks (Bausteine). There is no Kafka-specific one; for streaming, what matters is: - CON.1, the cryptographic concept - OPS.1.1.5, logging - ORP.4, identity and access management - the network and application building blocks The Compendium is also the audit basis for certification as "ISO 27001 on the basis of IT-Grundschutz", which ties the DACH trust anchor to the international standard. ## The core Kafka problem: immutable by design Kafka is an immutable, append-only log. It is precisely this property that makes event streaming attractive, because it guarantees ordering, replayability and a reliable source of truth. And it is precisely this property that collides with regulation. A record produced to a topic cannot simply be removed everywhere on demand. Kafka has retention, compaction and administrative deletion mechanisms, but they do not by themselves solve erasure across topics, replicas, backups, dead-letter queues, connectors and downstream consumers. That creates the tension with Art. 17 GDPR. Personal data may then sit in cleartext in the log and in backups unless you have client-side or proxy-side encryption; disk-level encryption is not enough, because it protects the volume, not what an authorized consumer reads. Native Kafka ACLs are coarse and hard to operate at scale and keep audit-proof. Lastly, Kafka delivers no continuous, queryable audit trail of who produced, consumed, configured or exported what. On top of that, Kafka natively provides only coarse primitives: TLS, retention and ACLs. Fine-grained encryption, masking, auditing and tenant-aware governance are not in the box; they have to be layered on top. To make Kafka defensible in regulated environments, you build a control layer around it. ## The mapping between requirements and controls If you translate the obligations from DORA, GDPR and IT-Grundschutz into technical controls, this is what you get: | Technical control | DORA | GDPR | IT-Grundschutz | |---|---|---|---| | Encryption & key management | Pillar 1 (risk mitigation) | Art. 32 | CON.1 | | Erasability despite immutability | Pillar 1 | Art. 17 | CON.6, CON.1 | | Access control & roles | Pillar 1 | Art. 5, 25, 32 | ORP.4 | | Data minimization & PII masking | Pillar 1 | Art. 5, 25, 32 | CON.2, ORP.4 | | Visibility of data flows (lineage) | Pillar 1 (risk analysis) | Art. 5, 30 | Structure analysis (200-2) | | Logging & audit | Pillar 2 (incident reporting) | Art. 30, 33 | OPS.1.1.5 | | Monitoring, resilience, recovery | Pillar 1 & 3 | Art. 32 | DER, OPS, CON.3 | | Control over ICT third-party providers | Pillar 4 | Art. 28, Chapter V | OPS.2.3 Use of outsourcing | | Tenant isolation | Pillar 1 | Art. 5, 25, 32 | ORP.4 | Most of these controls can support more than one framework at once: - One encryption and key concept supports Pillar 1 of DORA, Art. 32 of GDPR, and CON.1 of IT-Grundschutz. - One continuous audit log supports incident classification and reporting under DORA, personal-data-breach reporting under GDPR, and the logging IT-Grundschutz requires under OPS.1.1.5. ## The shared control landscape, in practice This layer is the critical point of a governance and security platform for Kafka. At Conduktor, we work with many German and European businesses that need to navigate this maze of technical requirements and turn them into regulated controls. Conduktor can provide this layer via its [Console](https://www.conduktor.io/console) (governance, visibility, operations) and its [Gateway](https://www.conduktor.io/gateway) (a Kafka proxy in front of the clusters, controlling data as it passes through the proxy). With the right deployment model, the controls above become centrally enforceable rather than scattered across individual applications. ### Encryption and erasure The Gateway can encrypt data as it passes through the proxy, before it is stored in Kafka, so these controls live in one place instead of in every application: - **Encryption:** whole messages or individual fields, via [envelope encryption](https://docs.conduktor.io/guide/use-cases/encrypt-kafka) (KEK/DEK/EDEK), with keys controlled through your own KMS (AWS, Azure, GCP, HashiCorp Vault, Fortanix). Encryption happens at the Gateway before data reaches Kafka, so the broker, even a managed one, only holds ciphertext for the protected fields or payloads. - **Erasure:** encryption enables [crypto-shredding](https://www.conduktor.io/blog/crypto-shredding-in-kafka-a-cost-effective-way-to-ensure-compliance) patterns. Scope key material to a person, account or business object, make that key material unusable when erasure is required, and the record may remain physically in the log while the information becomes permanently unreadable. This is one technical pattern for implementing erasure on an append-only log. - **Pseudonymization:** The Gateway can swap sensitive values for format-preserving, deterministic tokens, so they remain queryable and aggregable without exposing the original value. > **Supporting non-EU cloud transfer assessments.** In non-EU managed cloud environments, this pattern can support GDPR transfer risk management: keep encryption and decryption inside the organization's trust boundary, keep keys under the organization's control, and ensure the provider only holds ciphertext rather than cleartext Kafka data. Under the EDPB's Schrems II guidance, effective encryption can be a supplementary measure for third-country transfers (Chapter V), but it does not remove the need for a transfer assessment. (Same architectural pattern in US federal work: [FedRAMP High for Kafka without replatforming](https://www.conduktor.io/blog/fedramp-high-for-kafka-without-replatforming).) ### Access control, policies and masking Kafka's native ACLs govern only the broker: who can read or write topics. They don't reach the rest of the platform, like Kafka Connect for data integrations, or the Schema Registry where the data contracts live. Conduktor closes that gap: - **RBAC across the platform:** precise [roles and permissions](https://docs.conduktor.io/guide/conduktor-in-production/admin/set-up-rbac) extend the same authorization to schemas through Conduktor's Schema Registry proxy, with service accounts managed centrally. - **Policies at write time:** a Resource Policy can refuse a topic before it is created, for example one with too low a replication factor (a resilience risk) or without a required data-classification label. That supports data protection by design and the DORA resilience baseline, both enforced up front. - **Masking, separate from encryption:** Console hides sensitive fields in the operator UI; the Gateway [masks or transforms them in the data path](https://docs.conduktor.io/guide/conduktor-in-production/admin/data-mask) for consuming applications, driven by schema tags such as PII, GDPR or ENCRYPT. - **Federated ownership:** each application is declared with an owner, and the platform derives its permissions and naming from that declaration instead of granting them ticket by ticket, so accountability scales instead of bottlenecking growth. ### Visibility for the record of processing activities Art. 30 requires a record of processing activities (RoPA): for each processing activity, which personal data, for what purpose, by whom, to which recipients, kept how long, and protected how. Conduktor can make the technical side of that record queryable: - **Application resources** bundle Kafka resources (topics, consumer groups, subjects, connectors) with their owner, policies and business metadata such as purpose, data categories and retention, maintained under approval or GitOps workflows. - **Lineage** adds the actual flows between them: who produces, who consumes, what depends on what. Console provides the framework and the intelligence to connect the dots. It makes the technical reality visible; the usage, interpretation and legal assessment stay yours. ### Audit, resilience and third parties - **Audit:** Console emits [CloudEvents-format audit logs](https://docs.conduktor.io/guide/conduktor-in-production/admin/audit-logs) across Kafka, IAM, self-service and admin events into a Kafka topic; the Gateway logs authentication and every policy intervention. That is an evidence base for GDPR breach assessment and for DORA incident classification and reporting. - **Resilience:** the Gateway can fail clients over from a primary to a secondary cluster with no reconfiguration (they stay connected to the Gateway), and its [Chaos Testing features](https://docs.conduktor.io/guide/use-cases/chaos-testing) can inject latency, simulate broker outages or corrupt messages to test whether client applications survive them, which supports the kind of application-level resilience testing DORA's Pillar 3 expects. - **Third parties:** a managed Kafka (Confluent Cloud, MSK, Aiven) is itself an ICT provider under DORA; the Gateway can sit in front of it, so your governance can remain consistent even on infrastructure you do not run. Conduktor itself enters that assessment too: SOC 2 Type 2, regular penetration tests, vulnerability scanning, encrypted credential storage. ### Tenant isolation Most teams run many applications on shared clusters, so isolation is what stops one tenant from reading or disrupting another's data. Conduktor provides Virtual Clusters on Physical Clusters, to give each team its own logical cluster, RBAC and application ownership scope every access to what a team owns, and Partner Zones fence off external partners, all on the same physical brokers (ORP.4). ## Our controls, your governance model We deliver the building blocks. We do not decide for you: - What counts as personal data - Which retention periods apply - What your role model looks like That interpretation stays yours. Conduktor provides technical controls and evidence; the governance model, data classification, retention concept and final control assessment remain organizational responsibilities. If you would rather not make those calls alone, we can point you to implementation and consulting partners who set up the governance model, data classification and evidence trail with you. ## Conclusion: one control layer, three frameworks DORA, GDPR and IT-Grundschutz often converge on the same manageable set of controls around an immutable log: encryption, erasability, access control, masking, visibility, audit, resilience, third-party control and tenant isolation. Build this layer once around Kafka and you create one evidence base for all three. The first step is to bring streaming out of the blind spot and treat it like any other business-critical platform: one dedicated concept for governance, risk and compliance, instead of measures scrambled together under audit pressure. Conduktor Console and Gateway can provide that layer, from encryption and access control through audit to resilience. Bitvavo, a regulated exchange, runs Conduktor to [support DORA and MiCA compliance](https://www.conduktor.io/customer-stories/bitvavo-ensures-compliance-dora-mica). Want to see it mapped onto your own Kafka landscape? [Talk to us](https://www.conduktor.io/contact/demo).