Does DORA apply to Kafka?

DORA applies to financial entities, not to software. But if Kafka carries data that supports a critical or important function, it is part of the ICT systems DORA covers. Backup, restore testing, access control and provider risk all apply to it.

What does DORA Article 12 require for backups?

A documented backup policy with scope and minimum frequency, restore and recovery procedures, periodic testing, recovery onto systems segregated from the source, and recovery time and recovery point objectives per function.

Is Kafka replication enough for DORA or NIS2?

Usually not on its own. Replication keeps you online, but it copies deletes, bad writes and attacks to the standby. Both laws expect backup and recovery you can test. Most teams keep replication and add a separate, locked backup.

What are the NIS2 incident reporting deadlines?

Under NIS2 Article 23, an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month of that notification. National law can add detail.

Does using a managed Kafka service move the responsibility?

No. DORA Article 28 says financial entities remain fully responsible when they use ICT providers, and need exit strategies for services that support critical functions. Plan how you would move your data and your backup.

Can Lascaris run inside our own environment?

Yes. Lascaris is managed by Scalytics in your own cloud, or your team runs it on-prem or air-gapped. It works with Confluent, Apache Kafka, Redpanda and MSK.

Kafka DORA and NIS2 Checklist: 10 Checks for Auditors

Who is in scope

Two laws. Same question: can you recover?

DORA is a regulation that applies directly to EU financial entities. NIS2 is a directive that each member state turns into national law for essential and important entities in sectors such as energy, transport, health and digital infrastructure. The wording differs. For Kafka, the work is almost the same.

DORA

Banks, insurers, investment firms, payment firms

Detailed rules on ICT risk, backup and restore, testing, incident reporting and third-party providers. Applies from 17 January 2025.

NIS2

Essential and important entities

Risk measures that include backup management, disaster recovery, supply chain security, encryption and access control, plus fixed incident reporting deadlines.

Why Kafka

The stream is the system of record in motion

If a topic carries data a critical function depends on, losing it or corrupting it is an ICT incident. That makes the cluster, its backups and its provider part of the audit.

The gap

Replication is not the answer auditors want

A standby keeps you online. It also copies deletes, bad writes and attacks. Both laws expect a backup you can restore and a test that proves it.

The checklist

Ten checks for Kafka under DORA and NIS2.

Go through them with your platform and risk teams. A "no" on any line is a finding waiting to happen.

Check	What the law asks	What it means for Kafka
1. A written backup policy	Backup scope and minimum frequency, based on how critical the data is. DORA Art. 12(1) NIS2 Art. 21(2)(c)	List the topics that support critical functions, how often they are backed up and how long history is kept. "We replicate everything" is not a policy.
2. Backup separate from replication	Restore onto systems physically and logically segregated from the source, protected from unauthorised access or corruption. DORA Art. 12(3)	A standby cluster that shares credentials and automation with production is not segregated. Keep a copy outside the reach of production keys.
3. A copy nobody can change	Minimise the risk of corruption or loss of data and protect integrity. DORA Art. 9(2), 9(3)	Store backup segments on object storage under object lock, so an admin, a script or ransomware cannot delete or rewrite them before retention ends.
4. Restores you actually test	Test backup and restore procedures periodically. Test continuity and recovery plans at least yearly, with cyber attack scenarios. DORA Art. 12(2), 11(6)	Run restore drills into a parallel environment on a schedule. Keep the date, scope, duration and result of every drill.
5. RTO and RPO per function	Set recovery time and recovery point objectives per function, based on criticality. DORA Art. 12(6)	Write down how much stream data you can lose and how long a critical consumer can be down. Then show drill results against those numbers.
6. Integrity checks after recovery	Run checks and reconciliations so data stays consistent after recovery. DORA Art. 12(7)	After a restore, prove the offsets, counts and key ranges match. Point-in-time history lets you return to the moment before a bad write.
7. Least-privilege access	Limit access to what is required, with strong authentication and managed access rights. DORA Art. 9(4)(c), 9(4)(d) NIS2 Art. 21(2)(i), 21(2)(j)	Separate roles for producers, consumers, admins and backup operators. MFA for admin access. No shared super-user key that reaches both production and backup.
8. Encryption in transit and at rest	Protect data at rest, in use and in transit, and have a cryptography policy. DORA Art. 9(2), 9(3)(a) NIS2 Art. 21(2)(h)	TLS between clients and brokers, encrypted storage for the cluster and the backup, and keys managed by you.
9. Incident reporting on the clock	NIS2: early warning within 24 hours, notification within 72 hours, final report within one month. DORA: initial, intermediate and final reports to your authority. NIS2 Art. 23(4) DORA Art. 19	You need audit logs that show what happened to which topic and when. Without them, the 24-hour clock runs while you guess.
10. Provider risk and an exit plan	You stay fully responsible when you use ICT providers. Exit strategies for services that support critical functions. Supply chain security. DORA Art. 28(1)(a), 28(8) NIS2 Art. 21(2)(d)	If your Kafka or your backup is a managed service, show you could move it without disruption. A backup that only one vendor can read is a lock-in risk. Open formats and standard Kafka consumers lower it.

Article references point to Regulation (EU) 2022/2554 (DORA) and Directive (EU) 2022/2555 (NIS2) as published on EUR-Lex. NIS2 applies through national law, so check your member state's version. This is general guidance, not legal advice.

What to show the auditor

Six documents that close most Kafka findings.

Policies on paper are not enough. Auditors ask for evidence. Have these ready before they ask.

1. Topic criticality map

Which topics support which critical or important functions, with the owner of each.
2. Backup policy

Scope, frequency, retention and where the locked copy lives. Signed off by risk.
3. Restore drill log

Every test with date, topics, time to recover and data lost, set against your RTO and RPO.
4. Access review

Who can write, read, administer and delete, on production and on the backup. Reviewed on a schedule.
5. Audit trail

Logs of admin actions and data access you can search within hours, not days.
6. Exit plan

How you would move your Kafka and your backup to another provider or in-house, and how long it would take.

How Lascaris helps

Close the Kafka lines on the checklist without replacing Kafka.

Lascaris sits next to the Kafka you already run. Production and your replication stay as they are. You get a locked backup, tested recovery and the evidence that goes with it.

Check	How Lascaris covers it
Separate, locked backup	An immutable copy on S3 under object lock that production credentials cannot reach.
History and recovery	Time-indexed history kept for years on object storage. Recover into a parallel environment and run drills there, without touching production.
Exit and lock-in	Works with any Kafka-protocol source: Confluent, Apache Kafka, Redpanda and MSK. Standard Kafka consumers read the backup. Open core under Apache 2.0.
Where it runs	Managed by Scalytics in your own cloud, or self-run on-prem or air-gapped. Your data stays in your environment.

Lascaris does not replace your access model, encryption keys or incident process. It gives your teams a copy and a log they can rely on when those processes kick in.
Restoring a single topic as of a chosen time into a new topic is planned, not yet available.

Kafka backup vs replication Kafka backup and recovery on S3 Explore Lascaris Kafka platform options

Next step

Walk the checklist with us before the auditor does.

Book a call and we go through the ten checks against your Kafka setup, show where the gaps are and what a restore drill would look like. Or start with the AI Architecture Score to see where your stack stands today.

Book Your Call Get Your AI Architecture Score

FAQ

Common questions.

Is Kafka replication the same as backup?

No. Replication keeps a second cluster in step with production so you stay online during an outage. It also copies deletes, bad writes and changes made with stolen credentials. A backup is a separate, locked copy with its own history that production cannot change.

Are Cluster Linking and MirrorMaker 2 good tools?

Yes. They are the right tools for availability, disaster failover and moving data between sites. Scalytics is a Confluent partner and supports teams that use them. They are not designed to be a backup, so most teams need both.

What does a real Kafka backup need?

Four things: an immutable copy that cannot be changed or deleted early, credentials that are separate from production, history you can go back to from before an incident, and recovery that you test on a schedule without touching production.

Does Kafka backup matter for DORA and NIS2?

Yes, if your event streams carry critical business or operational data. Both frameworks expect you to back up critical data, protect it from attacks and prove you can restore it. A tested, locked backup gives you that evidence.

Do we have to replace our Kafka cluster to add backup?

No. Lascaris works with any Kafka-protocol source, including Confluent, Apache Kafka, Redpanda and MSK. Your production cluster and your replication stay as they are.

Can we restore a single topic to a point in time?

Today the backup keeps a time-indexed, immutable copy that standard Kafka consumers can read for replay and recovery drills. Restoring a single topic as of a chosen time into a new topic is planned, not yet available.

Your Kafka carries critical data. Can you prove it to an auditor?