Apache Kafka for DORA ICT risk requirements: what Kafka covers and what it does not
A financial entity that runs event streams carrying critical or important functions needs to know which DORA obligations a Kafka cluster can help meet and which stay with the entity. Kafka helps with the protection, prevention, backup and replication parts of Articles 9 and 12 of Regulation (EU) 2022/2554 (DORA), which has applied since 17 January 2025. Policy, periodic testing, recovery objectives, incident handling and supervisory evidence remain the entity's job. DeployOpen plans, builds and documents the platform and prepares systems and evidence for review, but it does not certify DORA compliance or issue attestations. Competent authorities supervise compliance, and independent assessors and the entity's own governance decide whether the controls are sufficient.
On the protection side, Kafka provides TLS encryption for client, broker and tool traffic and SASL mechanisms for authentication, but security is optional in Kafka, so the entity must enforce secured listeners and disable unsecured ones itself. Authorization in KRaft clusters uses ACLs stored in the metadata log, and the entity must confirm that allow.everyone.if.no.acl.found is not set to true. Data at rest encryption, network segmentation, privileged access management and logging of administrative actions are outside Kafka and must be designed in the surrounding platform. Ask your team to map each Article 9 sub-requirement to a named Kafka setting, a platform control or a written policy, and to identify any gaps before the design is final.
On the recovery side, MirrorMaker 2 replicates topics, consumer group offsets and ACLs between clusters, which supports a standby site, but replication is not a backup under Article 12. Article 12 asks for documented backup scope and frequency based on data criticality, restoration procedures, backup systems that can be activated without jeopardizing security or data integrity, and periodic testing. Replication copies mistakes and corruption as quickly as good data, so the entity must decide how it will keep point-in-time copies of topics and configuration. Recovery time and recovery point objectives for each event stream are business decisions the entity must set and approve, and the restoration tests must prove they can be met. Confirm with your architects which topics fall under critical or important functions before choosing the replication and backup design.
Mapping DORA Articles 9 and 12 to Kafka capabilities and configuration
This table maps each DORA Article 9 and 12 requirement to the Kafka capability that supports it and the configuration you need to set. Read each row as a control you must implement and evidence, not a feature Kafka enables by default. The main takeaway is that Kafka's security features are optional, so the listener and authorization settings must be mandated and verified.
| Requirement | Kafka capability | Configuration and evidence to keep |
|---|---|---|
| Article 9(1) and (2): continuous monitoring and control | Kafka exposes broker and client metrics, but the documentation does not treat monitoring as a built-in control | Forward broker, controller and authorization logs to your monitoring platform. Alert on listener changes and ACL edits. Ask the vendor or your team to confirm which metrics your version exposes. |
| Article 9(2): protection of data in transit | SSL/TLS encryption between clients, brokers and tools. Security is optional, so unsecured listeners can exist | Define only SSL or SASL_SSL listeners in broker configuration. Disable PLAINTEXT listeners and block them at the network layer. Keep certificate inventory and rotation records. |
| Article 9(2): protection of data at rest and in use | Kafka does not provide application-level encryption of stored log segments in the documentation reviewed | Use encrypted volumes or disk encryption on broker storage. For sensitive fields, encrypt payloads before producing. Document key custody and who can read broker disks. |
| Article 9(4)(a): documented policy and access control | SASL mechanisms (GSSAPI, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512, OAUTHBEARER) and pluggable authorization | Prefer Kerberos, OAUTHBEARER or SCRAM over PLAIN. Keep the access policy in a versioned document that maps identities to topic and group ACLs. |
| Article 9(4)(b): network structure and isolation | No automated isolation feature is described in the Kafka security documentation. Isolation comes from the network platform | Place brokers in restricted network segments. Limit controller and broker ports to known peers. Ask your network team to document the automated isolation trigger, if one is used. |
| Article 9(4)(c): limited logical and physical access | StandardAuthorizer stores ACLs in the KRaft metadata log. Resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is true | Keep allow.everyone.if.no.acl.found set to false. Limit super.users to a small named group. Review ACL exports on a set schedule and keep them as evidence. |
| Article 12(1): backup scope, frequency and restoration | MirrorMaker 2 replicates topics with configuration, consumer group offsets and ACLs to another cluster. It is replication, not a point-in-time backup on its own | Set the replicated topic list by criticality. Define the replication lag you accept and the restoration steps in a written procedure. Back up cluster metadata and topic configuration separately. |
| Article 12(2): backup systems that can be activated safely and tested | MirrorMaker 2 can run against a standby cluster that keeps the same topic partitioning and ACLs | Test failover to the standby cluster on a schedule. Check data integrity and ACL parity after each test. Record results, failures and remediation as evidence. |
How Kafka's security and replication features map to protection and recovery
Kafka's documented security features cover three of the protection points in DORA Article 9: encryption of traffic, authentication of who connects, and limits on what each identity may do. Kafka encrypts traffic between clients, brokers and tools with SSL/TLS, but security is optional, so the cluster can still run unsecured or mixed listeners. For a regulated entity, the practical control is to define every listener as TLS-secured, disable plaintext listeners for production, and keep that configuration under change control so auditors can see the baseline. Authentication uses SSL or SASL, with GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER as the documented SASL mechanisms. Choose one mechanism per client population and record the choice in your information security policy.
Access limits come from the authorizer. In KRaft clusters the StandardAuthorizer stores ACLs in the cluster metadata log, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Keep that setting at its default for production, and review super user membership and ACL exports on a schedule, since these records are the evidence for the access policies Article 9(4)(c) asks for. Confirm with the vendor or your identity team how external authorization services would integrate, because the supplied documentation describes pluggable authorization without detailing a specific integration. Storage-layer encryption at rest is not a Kafka broker feature covered by the documentation used here, so confirm disk or volume encryption with your storage platform or cloud provider.
For recovery, MirrorMaker 2 is the documented route to a second cluster. It is built on Kafka Connect and replicates topics with their configuration, consumer groups with offsets, and ACLs between clusters, preserving partitioning. That covers the data, the consumer positions and the access rules needed to resume service elsewhere. It does not by itself prove a restoration procedure works, so Article 12(2) testing still needs a runbook for failover, a defined recovery point, and periodic drills that check consumers resume from the replicated offsets. Ask the team to state the replication lag they accept and how they measure it, and confirm which parts of the mirror configuration are needed for your recovery objectives.
Evidence a supervisor or auditor will ask for from a Kafka platform
A supervisor reviewing a financial entity's ICT controls will ask to see how Kafka is secured, who can use it, how it recovers and how it changes over time. The items below are the records that answer those questions, and each one needs an owner and a refresh routine so it reflects the cluster as it runs today.
Written ICT security policy and Kafka standards
Article 9 expects a documented information security policy, and a Kafka-specific standard should sit beneath it. The standard should state which listeners must use TLS, which SASL mechanisms are approved, how ACLs are granted and how topics are classified by criticality and confidentiality. Review it at each planned Kafka release and whenever a new data class enters the platform. The information security function signs the policy, and the Kafka platform owner signs the standard.
Cluster configuration exports
Export the broker and controller configuration on a fixed schedule and keep the files under version control. Auditors look for listeners that carry only TLS or SASL, an authorizer class set for the KRaft cluster and confirmation that allow.everyone.if.no.acl.found is not true. Compare each export with the approved baseline and record every deviation with a reason. The platform owner prepares the export and the security reviewer signs off on the comparison.
ACL listings and access reviews
In KRaft clusters the authorizer keeps ACLs in the metadata log, so a current listing can be produced from the cluster itself. Review who holds write, read and admin rights on critical topics and consumer groups, and remove grants tied to people who have left or to services that no longer exist. Keep each review dated, with the reviewer's name and the changes made. The application owner approves access to their topics, and the security team confirms the review was completed.
MirrorMaker 2 configuration and lag records
Where cross-site replication supports recovery, keep the MirrorMaker 2 configuration for each replication flow, including the topics, consumer groups and ACLs it copies. Record replication lag at regular intervals so the entity can show how far a standby site trails the primary. These records feed the recovery objectives for event streams. The platform team maintains the configuration, and the operations lead signs the lag reports.
Backup and restore test records
Article 12 requires periodic testing of backup and restoration procedures, so each test needs a dated record. Note the scope restored, the time taken, whether consumers resumed from the expected offsets, and any data integrity checks performed. Record failed tests and the corrective actions with their closure dates, since supervisors read the failures as closely as the passes. The resilience owner runs the test and the business continuity lead approves the result.
Upgrade change records
Every Kafka upgrade should leave a change record that names the source and target versions, the upgrade notes reviewed, the rolling upgrade sequence and the rollback plan. Supported releases should be checked against the downloads page before a change is raised, and any move from an older KRaft release should follow the recommended path through 3.9.x. Link each change to its test evidence and post-change checks. The change board approves the change and the platform owner closes the record.
Configuring Kafka for DORA Articles 9 and 12 in sequence
This sequence turns the DORA Article 9 and Article 12 requirements into a configured Kafka platform with classified topics, secured access, a tested second site and recorded restore results. Each step produces evidence that an internal audit or supervisor can check.
Classify event streams by criticality and confidentiality
Start by inventorying every topic, consumer group and connector that carries data for a critical or important function, and record its criticality and confidentiality level. The financial entity's risk owner and the data owner sign off on the classification, because it sets the backup frequency, the replication scope and the access rules in later steps. Article 12(1) ties minimum backup frequency to this classification, so the register is the input to the policy. Done means every topic has an owner, a class and a recovery expectation recorded in a controlled document.
Write the backup and recovery policy
Draft the documented backup policy and restoration procedures covering the scope of data backed up, the minimum frequency for each class, and the recovery methods for brokers, metadata and mirrored topics. Include what is backed up beyond topic data, such as the KRaft metadata log, broker configuration, ACL definitions and the MirrorMaker 2 configuration. Ask the ICT risk function and the business owners to approve the document before any build work starts. Done means an approved policy exists that maps each topic class to a backup and recovery method.
Confirm the release and upgrade path
Select the Kafka release line that your support and patching plan can follow. The current supported releases on the Kafka downloads page are 4.3.1, 4.2.2 and 4.1.2, and all earlier versions are archived. Follow the upgrade notes for any move from an older KRaft cluster or a ZooKeeper-based cluster, because Kafka 4.0 removed ZooKeeper mode and older KRaft clusters should first reach 3.9.x. Confirm the Java runtime requirement with the upgrade notes before building images. Done means a written version decision and a tested upgrade route are on file.
Deploy KRaft with secured listeners and SASL
Deploy the cluster in KRaft mode with TLS on every listener that carries client, broker or tool traffic, and enable SASL on client listeners using a mechanism your identity design supports. The security overview documents GSSAPI, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER, and security is optional by default, so unsecured listeners must be disabled explicitly. Store keys and certificates in your controlled secrets store. Done means a port scan and a client connection test show that only the approved secured listeners accept traffic.
Set StandardAuthorizer with default-deny ACLs
Enable the StandardAuthorizer, which keeps ACLs in the cluster metadata log, and leave allow.everyone.if.no.acl.found unset or false so that resources without an ACL are limited to super users. Create ACLs per topic, consumer group and transactional ID from the classification in the first step, and keep the super user list short and documented. Review that connectors and mirroring identities hold only the permissions they need. Done means an access review export lists every principal and grant, and a negative test confirms an unlisted client is denied.
Configure MirrorMaker 2 to a second site
Build MirrorMaker 2 on Kafka Connect to replicate the topics classed for recovery to a second cluster in a separate failure domain. It replicates topic configuration, consumer group offsets and ACLs, and preserves partitioning, so confirm the replicated ACLs match your default-deny model at the target. Set the replication scope and lag alerting from the classification, and record the target cluster's security settings with the same standard as the primary. Confirm the geographic and sovereignty constraints for the second site with your compliance team. Done means replicated topics on the second site show current offsets and matching ACLs.
Define restoration procedures and failover roles
Write step-by-step restoration and recovery procedures for each failure scenario in the policy, including loss of a broker, loss of the metadata quorum, loss of a site, and corruption of a topic. Name the roles that can activate the second site, the approvals required, and how the team confirms data integrity and ACL state after switching. This addresses the Article 12(2) expectation that backup systems can be activated without jeopardising security or data integrity. Done means each procedure has a named owner, prerequisites and a verification step, and a tabletop exercise has reviewed them.
Schedule periodic restore tests with recorded results
Schedule restore and failover tests at the interval the policy sets, and run them against the documented procedures, not against an improvised sequence. Record the scope, the data checked, the time taken, the defects found and the corrective actions, and have the owner sign the result. Feed the findings back into the classification and the policy when recovery gaps appear. Article 12(2) requires periodic testing of both backup and restoration procedures, so the signed test log is the core evidence an assessor will ask to see. Done means a dated test record exists for each class of topic and each open finding has an owner.
Questions financial entities ask before hiring help for Kafka and DORA
What drives the effort of a Kafka and DORA engagement?
The main drivers are the number of clusters, topics, Kafka Connect deployments and sites, plus how much written policy and evidence already exists. A single cluster with documented backup and access procedures takes far less work than several clusters across two data centers where nothing is written down. Other drivers include how many systems consume the streams, whether any topics carry data tied to critical or important functions, and how many restoration tests the entity wants to run. Ask your team to list these items before requesting a scope, because each one changes the design, the testing and the documentation that DeployOpen would write.
How long does a Kafka DORA engagement take?
The duration depends on the written scope, which is agreed before work starts and sets the deliverables and timelines. DeployOpen does not give a duration on this page. The scope should state which clusters are covered, which Article 9 and Article 12 controls are in scope, which restoration tests will run, and who signs off each deliverable. Timelines often depend on your internal approval cycles and change windows as much as on the technical build, so include those dates in the scope discussion. Confirm with the team how restoration testing will be scheduled against production change freezes.
What does the financial entity need to provide for the work?
The entity needs named owners for the Kafka platform, information security policy, business continuity and third-party risk, because each of these areas produces evidence that DORA expects. It also needs access to the environments under work, including test clusters that can be used for restoration exercises. Criticality data is required so that topics and their recovery objectives can be ranked against the functions they support. Finally, someone with authority must sign off the policies, procedures and test results. Without these, the documentation will describe a platform the entity cannot yet operate.
Can our own team implement these controls without outside help?
Yes, a capable team can do this with the Apache Kafka documentation and enough time for design, configuration and testing. The security overview, authorization documentation and geo-replication guide cover the settings for encryption, access control and MirrorMaker 2. The work that is easy to underestimate is the testing: backup systems must be shown to activate without jeopardizing security or data integrity, and restoration procedures must be tested periodically. Plan the internal staffing for that testing and for the written procedures, not only for the initial configuration.
Does DeployOpen certify that our Kafka platform is DORA compliant?
No. DeployOpen plans, implements, hardens and documents the platform and prepares the systems, controls and evidence for a compliance assessment. It does not issue audit reports, attestations or certifications. DORA sets no certification scheme, so competent authorities supervise compliance using their own powers, and the only authority-issued attestation the Regulation provides for concerns a threat-led penetration test under Article 26(7). Your supervisor, or the independent auditor you engage, makes the assessment. Ask any partner who offers a DORA certificate to explain which body issues it.
How is the cost of a Kafka and DORA engagement quoted?
DeployOpen does not publish a price list. A quote follows from the written scope, which lists the clusters, sites, topics in scope, deliverables, testing and any retainer for ongoing support or continuous testing. Ask the quote to separate the one-time build, policy and evidence work from recurring items such as support, upgrades and periodic restoration exercises. Also ask which costs fall on your own staff, such as change approvals, infrastructure and internal reviews, because those are paid from your budget rather than the engagement. Compare quotes on the same scope, not on headline totals.
How supervisors read DORA evidence for event streams
Competent authorities supervise DORA compliance using the powers in Article 50, and DORA sets no certification scheme for ICT platforms. No one hands you a DORA badge for a Kafka cluster. Supervisors instead look for evidence that the controls described in your ICT risk framework operate in practice, are monitored, and are tested. For a Kafka platform, that means being able to show the configuration as it actually runs: listeners that require TLS, SASL mechanisms in use, the StandardAuthorizer state and ACLs in the metadata log, and records of who changed them. A design document that says the cluster is secured is weak evidence on its own. Exports of the live broker configuration, change tickets linked to them, and access reviews that compare ACLs against approved owners are stronger.
Backup and restoration need the same treatment. Article 12(2) expects periodic testing of backup procedures and of restoration and recovery procedures and methods, so a replica in a second site is not enough by itself. Set out a dated test plan for the topics in scope, and keep the results: which topics and consumer group offsets were restored, into which cluster, how long it took against the recovery objectives you set, and what was found and fixed. For MirrorMaker 2, record how topic configuration, consumer group offsets and ACLs were checked after failover, because those are the parts that a naive restore often misses. Confirm with your supervisor how much of this must be documented in advance and how much can be produced on request. The Digital Omnibus proposal (COM(2025) 837, procedure 2025/0360(COD)) would amend parts of the digital regulation framework that includes DORA. It is still a proposal. Before you finalize the evidence plan, check its current legislative status and whether any amendment touches Articles 9, 12 or the reporting obligations you rely on, using the Digital Omnibus proposal on EUR-Lex and the procedure record on the European Parliament Legislative Observatory.
How DeployOpen scopes and delivers DORA-ready Kafka platforms
DeployOpen plans, builds and hands over self-hosted Apache Kafka inside your own infrastructure, with the DORA Article 9 and Article 12 controls scoped in writing before work starts. Each engagement maps the Kafka settings and the surrounding platform controls to the evidence your team and supervisors will ask to see.
How we scope
- Agreed in writing before work starts, with the clusters, topics and data classes covered by the engagement named.
- Maps which Kafka settings and which surrounding platform controls address each Article 9 and Article 12 requirement in scope.
- Identifies the recovery objectives your team sets for event streams, so backup and replication design follows them.
How we build
- Configures KRaft clusters with SSL/TLS listeners, SASL authentication and ACLs, with no unsecured listeners left open.
- Designs MirrorMaker 2 replication to a second site and documents what topics, offsets and ACLs it carries.
- Plans backup scope, minimum frequency and restoration procedures alongside the topics they protect.
How we hand over
- Delivers written runbooks for backup activation, failover, restoration and periodic testing of those procedures.
- Documents the configuration baseline, access model and evidence sources so your auditors can trace each control.
- Records open items, such as controls your team or your cloud provider must confirm, so nothing is assumed in the handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Upgrade planning follows the Kafka upgrade notes and supported release lines, with each step tested before production.
- Recovery and restoration tests can be repeated on a schedule your team agrees, with results written up for supervisory review.
