NIS2, DORA, and Apache Kafka

TL;DR: NIS2 and DORA classify Apache Kafka data as business-critical, so they require provable and tested backup and recovery. Kafka replication protects against server failure, but does not cover accidental deletion, data corruption, or ransomware. To achieve full Kafka NIS2 and DORA compliance, teams need immutable off-site Kafka backups with point-in-time recovery and documented testing.

‍

Do NIS2 and DORA cover event data?

While the full texts of the NIS2 and DORA directives do not name event streaming platforms directly, regulators still care about the data running through them. Payment pipelines, order management systems, and audit trails make event hubs a critical data layer.

Under Article 21 of the NIS2 directive, any Kafka environment carrying load-bearing data falls under strict business continuity and backup management rules. Organizations using Apache Kafka must therefore be able to prove their recovery capabilities with concrete evidence.

DORA applies specific ICT risk management mandates to financial entities. For Kafka setups handling market data or transactions, DORA and MiFID II requirements demand offline capability and restoration procedures.

‍

What is the replication trap?

Engineering teams frequently rely on high availability setups for data protection. For example, a standard replication factor of three keeps systems online when a broker goes down.

However, Kafka replication is not a backup because it propagates errors instantly. If a bad deployment corrupts a topic, the cluster copies that bad data to all replicas immediately. High availability architectures also fail to produce the restore logs, recovery time metrics, or audit trails that an auditor expects.

‍

What does a compliant Kafka setup look like?

To make sure your setup meets all Kafka compliance regulations, your data protection strategy needs specific operational characteristics. Tools like Kannika Armory provide the necessary artifacts for an audit natively. Prefer to see it rather than read it? Watch our video walkthrough of proving Kafka compliance.

Operationally decoupled storage

Regulators expect backups to live outside the production control plane. Kannika Armory offloads data to isolated cloud storage or on-premises vaults so a cluster failure does not affect your recovery data.

Point-in-time recovery

The backup process needs to run continuously and capture data in real time. Using Kafka backup tools, you should be able to restore a specific topic to the exact moment before a ransomware attack or configuration mistake occurred.

Complete audit trails

A repeatable and documented restore process is mandatory. Every backup run, configuration change, and restore test should generate an automated log with timestamps and outcomes.

Review all Kannika Armory features to see how the platform builds these capabilities natively into your infrastructure.

‍

Your path to NIS2 and DORA Kafka compliance

To close the compliance gap for Kafka setups, you do not need a complete overhaul of your architecture. Instead, you need to take a few practical steps.

Define targets per workload

Start by identifying which topics hold data necessary for business continuity, because you don’t need to back up every stream. Focus on the data where a loss would disrupt operations, cause reporting failures, or break downstream systems.

Configure a backup solution

Set up a Kafka backup tool like Kannika Armory to back up the selected topics. The live cluster continues operating normally while the system writes data to isolated storage.

Execute a restore test

This is exactly what an auditor will want to see. Select a topic, run the recovery process into a test environment, confirm the data is intact, and save the resulting logs.

Write down the procedure

Record the entire backup and restoration process. Include the backed-up items, the storage location, the recovery method, and the final results to build your audit evidence pack.

Set a recurring schedule

Don’t just test once! Both regulatory frameworks demand continuous proof of operation, so a quarterly test is a good baseline for most teams.

‍

FAQ

Does Kafka replication meet NIS2 or DORA compliance?

No. Replication is an availability tool that copies data across brokers to prevent downtime. It copies corrupted data and deletions instantly. It also fails to provide restore logs or an audit trail for compliance.

What does NIS2 Article 21 require for Kafka?

Article 21 requires essential entities to implement risk management measures, including backup management and business continuity. If your business depends on event data, you must maintain and test a dedicated recovery capability for that platform.

How does DORA apply to Kafka in financial services?

DORA requires financial entities to maintain ICT business continuity policies for critical systems. When an event hub carries transaction or market data, DORA mandates strict backup policies, restoration procedures, and offline capability.

What is the difference between NIS2 and DORA for Kafka teams?

Both frameworks demand proven recoverability. NIS2 broadly covers essential sectors and requires business continuity controls. DORA specifically targets the financial sector with highly detailed testing and air-gapping obligations.

How do you prove Kafka recovery to an auditor?

You must present evidence of successful restore tests rather than just a policy document. Auditors look for documented recovery time metrics and an audit trail showing regular testing.

What happens if a Kafka backup fails a DORA test?

A failure exposes a compliance gap. Financial entities must demonstrate the ability to recover systems to a clean state. Failing a test means the current disaster recovery plan cannot meet the regulatory standard and requires immediate remediation.

‍

Ready to secure your data?

Let’s discuss your infrastructure setup and see how a NIS2 and DORA-compliant Kafka backup solution can help.

Contact us!