How NIS2 Article 21 applies to your Kafka environment

NIS2 never mentions Kafka. Search the full text of the directive and you won't find the word. So it's tempting to assume your Kafka environment sits outside the scope of the regulation. That assumption is wrong, and your auditor will explain why.

‍

NIS2 Article 21 backup and business continuity requirements

Article 21 of the NIS2 Directive sets out the cybersecurity risk management measures that essential and important entities must implement. It's written in broad, outcome-driven language. Rather than prescribing specific technologies, it defines ten areas where organizations must have controls in place and be able to prove those controls work.

Subsection C of Article 21 requires business continuity and backup management. It sits alongside incident handling, supply chain security, crypto policies, and access control. The directive doesn't tell you which systems need backups. It tells you that if your business depends on a system for continuity, that system is in scope.

This matters for Kafka because Kafka has quietly become a critical data layer in a lot of organizations. Payment processing flows through it. Order management systems depend on it. Fraud detection pipelines read from it. Inventory updates, audit trails, customer events, all of it moves through Kafka in real time. And in many of those setups, the data on Kafka is load-bearing. If it disappears, downstream systems lose their source of truth.

Under Article 21 subsection C, a system that carries data your business relies on for continuity falls under the backup management requirement. The fact that NIS2 doesn't name Kafka doesn't exempt it. It just means your team needs to make the connection, document it, and be ready to defend it in an audit.

‍

Why NIS2 demands provable backup recovery

Here's the part most teams underestimate. NIS2 doesn't just want you to have a backup strategy. It wants you to prove the strategy works in practice.

ENISA, the European Union Agency for Cybersecurity, has been explicit about this in its implementation guidance. Organizations must evidence what actually happens, not just what's planned. A backup policy document is a starting point, not evidence. What auditors want to see is a successful restore. A documented recovery time. A trail of test results showing the capability was exercised and the data came back intact.

This is a meaningful shift from earlier frameworks that accepted a strategy document as compliance. Under NIS2, a policy explains intent. Evidence proves the control is real. If you can't demonstrate a successful restore of your Kafka data, you don't have a backup for audit purposes.

‍

The NIS2 audit gap in replication-based Kafka setups

In practice, most Kafka environments are covered by replication. The team treats replication as the backup strategy because, historically, it was the only option available. That works for high availability scenarios, but it doesn't give you any of the provability that NIS2 requires. You can't restore from a replica. There's no audit trail of recovery tests. There's no recovery time metric because recovery isn't actually a capability, it's just a hope.

For an Article 21 audit, a replication-only setup is going to be difficult to defend. The auditor will ask for evidence of business continuity testing. The auditor will ask for the restore logs. The auditor will ask how long it takes to recover, and what data was recovered in the last test. Replication doesn't produce any of those artifacts.

‍

Getting your Kafka environment NIS2 compliant

The good news is that closing this gap doesn't require a multi-quarter project. With Kannika, configuring a real backup on your Kafka environment takes hours, not months. Your data gets backed up in real time, operationally decoupled from your cluster. Restores produce the logs and metrics your auditor is looking for. The audit trail is generated automatically as part of normal operations.

Kannika also runs in your own environment, which matters for compliance teams that don't want another SaaS vendor in their risk management inventory. Your data never leaves your infrastructure. You buy the license, your ops team installs it, and the backup runs locally. If you prefer to offload the operational side, we have a managed cloud offering that handles the installation and maintenance for you, with the data still staying in your environment.

‍

Talk to us before your audit cycle

If you're preparing for a NIS2 audit and your Kafka environment isn't covered, book a 30-minute call with our managing partner Wout. We can map your current setup against Article 21 and help you scope what compliance would look like for your specific situation.