Databases in the BSI blueprint: what the new practice guide changes operationally for relational, NoSQL, and containerized systems

On 6 May 2026 the BSI published its practice guide for the secure operation of relational, NoSQL, cloud, and containerized database systems. Addressed to leads in information security, IT operations, and IT architecture. The guide isn't a mandatory document in the NIS-2 sense, but it will very likely become the de-facto measurement yardstick by which auditors, cyber insurers, and NIS-2 supervisory bodies assess the database layer in German Mittelstand stacks from summer 2026 onwards.

Four content axes: (1) authentication and authorization with clean schema granularity and tenant separation; (2) encryption at rest (LUKS/dm-crypt, KMS) and in transit (TLS even for bridge networks); (3) container lifecycle with separate data and application containers and an isolated update path; (4) backup/restore plus data-exfiltration detection at the DB layer. Recommendation: 2–3 hours of first reading this week, mapping table within two weeks, TLS on every DB path within four weeks, a documented restore drill within three months.

What the guide contains

The practice guide, per the BSI, is not a product audit and not a MariaDB/PostgreSQL/MongoDB-specifics collection. It's an architecture and operations framework: which security decisions do I make when setting up a database layer, which when connecting it to an application, which across the lifecycle (backup, restore, migration, end-of-life), which when running a container that hosts a database?

The content focuses on four axes:

First — authentication and authorization. The guide addresses the notoriously thin role granularity in German SME stacks: a single application user with write permissions on the entire schema, an identical role for test and production database, no read-only path for reporting. The BSI recommends clean separation by function and tenant plus consistent use of schema privileges instead of table privileges.

Second — encryption at rest and in transit. The guide draws the line clearly: TLS on every database connection, even within a container composition. „Don't trust the bridge network“ is the one-sentence summary — a position that regularly meets the surprised „but it's an internal network“ in reviews. For encryption at rest the guide opts for storage-layer encryption (LUKS, dm-crypt, cloud-provider keys with your own KMS) instead of in-database TDE as an obligation — a pragmatic call for German SMEs.

Third — container lifecycle. Here the guide gets most interesting for modern stacks. A database in a container isn't a „normal“ container: backup volumes, persistence mounts, update paths, and restart behavior differ from stateless application containers. The guide recommends clean separation between data and application containers, dedicated encrypted volumes, and an update strategy that separates the image update from the schema update.

Fourth — backup, restore, and data-exfiltration detection. The guide draws a line that aligns with the Bitwarden pattern (UID 280): a backup that isn't restored regularly isn't a backup, it's an assumption. Alongside that it addresses the increasingly important question in NIS-2 context of data-exfiltration detection — logging and anomaly detection at the database layer itself, not just on the network layer in front of it.

Tool recommendations are deliberately absent. There's no „BSI-recommended backup operator“, no „BSI-certified TDE module“. That's the right call because the tooling field moves too fast. But it means the guide only lands in German Mittelstand stacks if advisory work or in-house architecture leads translate it into concrete configurations.

How the guide fits into NIS-2 and ISO 27001

Structurally the practice guide is part of a broader BSI initiative over the past weeks: at the end of April the C5:2026 standard for cloud services with first-time requirements on post-quantum cryptography and confidential computing, in early May the „Cyberdome“ buildup of national protection infrastructure, now the database guide as the operational reference. The line is consistent: the BSI is upgrading the measurement and assessment infrastructure for NIS-2 supervision, which becomes tangible from summer 2026 — the registration window has been closed since 6 March 2026.

For ISO 27001 shops, the guide slots neatly into Annex A controls 8.10 (Information deletion), 8.11 (Data masking), 8.24 (Use of cryptography), and 8.13 (Information backup). An existing ISMS can hang the guide into the existing risk matrix as a detail spec for the database layer, without spinning up its own project.

Anyone without a formal ISMS but running a DevSecOps-pragma stack gains a new tool for the conversation with the cyber insurer: from summer 2026 the insurer will ask, „which standard do you use to harden your database layer?“ — the practice guide is an answer that costs nothing and bears the BSI stamp.

What we concretely recommend

This week: read the guide once end-to-end. It's compact; a DevOps or DBA lead needs two to three hours to grasp the axes. Without that read, every next step is interpretation.

Within two weeks: build a mapping table. On one side the BSI recommendations from the four axes, on the other your current state. Where do you meet the recommendation, where don't you, where deliberately not (e.g. LUKS not enabled on bare-metal, but cloud-provider encryption in place). The mapping table is the document you put on the table in your next audit conversation.

Within four weeks: TLS on every database path. If you still run bridge-network traffic without TLS today (Sylius app container ↔ MariaDB container, TYPO3 pod ↔ PostgreSQL pod), that's the fastest, most visible, and most audit-friendly improvement. Self-signed certificates from your own CA are enough for internal paths; cert-manager in the K8s cluster automates the rotation.

Within three months: restore drill. Not a „backup test“ but a real restore into an isolated environment, with time measurement, data-consistency check, and a documented protocol. The guide doesn't make the drill mandatory, but it makes the absence of a documented restore drill the typical audit question.

What we deliberately don't recommend

We don't recommend kicking off a database migration just because the guide addresses NoSQL and relational systems in parallel. If you run productively and stably on MariaDB/PostgreSQL, you shouldn't switch to a document store or vice versa just because the BSI document covers both. The choice of database class is an architecture decision, not a compliance reflex.

We equally don't recommend relying on in-database TDE as a silver bullet. The guide pragmatically defaults to storage-layer encryption; in-database TDE is the more expensive variant with its own weaknesses (key management, performance, friction with backup tooling). If you have a choice, most German SME stacks come out cheaper and more robust with dm-crypt or KMS-managed cloud encryption.

Who is most affected

TYPO3 and Sylius hosting companies with multi-tenant setups that keep several customer databases in the same MariaDB or PostgreSQL instance — typical in hosting contracts with thin margins and shared infrastructure. The guide makes clean schema/tenant separation the expectation; if you run that today with a single application user holding write rights on everything, you have honest work to do.

SMEs with self-hosted database containers in Docker Compose, often as a companion container to a Sylius or Symfony application. Typical gaps here are in volume encryption, in the update strategy (image update pulls schema update with it without anyone noticing), and in backup discipline.

Clients within NIS-2 scope who haven't completed registration, in their ongoing audit preparation. Here the practice guide is a welcome anchor because it offers the supervisory body a concrete measurement yardstick for the database layer without forcing the client to build its own measurement system.

Conclusion

The practice guide isn't a sensation and doesn't trigger an acute security incident. It's a blueprint — and it's the kind of blueprint against which audit conversations, insurer questions, and NIS-2 clarifications will align over the coming months. Anyone ignoring it will still find it on the table at the next external meeting — just without their own mapping table.

The question isn't whether the guide is relevant for your database layer. It's whether you have the two hours for the first read and the two weeks for the mapping table today — or whether you'll do this work under audit pressure in autumn.

Personal context and technical detail on the TLS obligation in container compositions and on the restore drill in TYPO3/Sylius stacks: ole-hartwig.eu.