On 6 May 2026 the German Federal Office for Information Security (BSI) published a practice guide for the secure operation of relational, NoSQL, cloud, and containerized database systems. The guide isn't a binding norm but a reference framework for information security, IT operations, and IT architecture — and in exactly that role it becomes the measurement yardstick for audits, insurers, and NIS-2 assessments.
What has changed? The BSI delivers a compact reference for the database layer — architecture-near, not product-specific. Who should keep reading? Operators of TYPO3, Sylius, or Symfony stacks with database containers, multi-tenant hosting companies, and anyone with a NIS-2 or ISO 27001 audit on the calendar within the next six months. What's on today's list? First read-through, mapping table, TLS on every DB path — in that order.
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.
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.
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.
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.
I 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.
I 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.
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.
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.
Yes — but not as a regulatory duty. Three places where the guide bites even without NIS-2 scope: (1) Cyber insurers ask from summer 2026 onwards for a standard on the database layer; “BSI practice guide“ is a zero-cost answer. (2) B2B customers (especially KRITIS-bound clients) will cite the guide in supplier audits. (3) ISO 27001 Annex A mappings will adopt the guide as a detail specification, so an ISMS review will reference it even without formal NIS-2 scope.
For internal container-to-container paths, yes. An internal CA whose root certificate is trusted by all participating containers can be set up in a morning with cert-manager or a lean step-ca setup and solves the two real problems: encryption of bridge traffic and mutual authentication (mTLS). Public CA certificates (Let’s Encrypt, ZeroSSL) are out of place for internal paths — they require reachable domains and complicate rotation. The BSI guide demands TLS, not public-CA TLS.
With managed database services (AWS RDS, Google Cloud SQL, Azure Database for PostgreSQL) infrastructure responsibility sits with the provider — DB engine patching, volume encryption at rest, backup mechanics. You retain: authorisation granularity, TLS enforcement (RDS will connect without TLS unless the client requires it), application credential rotation, restore drills (cloud backup is not a tested restore path) and data classification. A BSI-conformant mapping table for cloud databases shows about two-thirds of the axes “green via provider“ — the remainder is operational duty.
Four components: (1) isolated target setup (own VM or own compose stack) that is production-like but does not write back to production. (2) Restore of the most recent backup (timed: from “command issued“ to “DB ready“). (3) Consistency checks — e.g. CHECKSUM TABLE in MariaDB/MySQL, pg_dump --schema-only diff in PostgreSQL, a sample-based integrity check on business-critical tables. (4) Log: a markdown file in the repo with timestamp, state, responsible person, anomalies. Six months later, that entry must answer an audit question without anyone still holding the drill in their head.
The guide pragmatically chooses storage-layer encryption (LUKS, dm-crypt on bare metal; KMS-managed volume encryption in cloud) as default. In-database TDE (e.g. InnoDB Transparent Data Encryption or pg_crypto-based column encryption) is not excluded, but conceived as an additional layer for especially sensitive data, not as the primary defence. In practice: storage-layer encryption is robust, performant and backup-friendly; in-database TDE brings key management friction, performance cost and complications with backup tools. For 90 percent of DACH SMEs, storage-layer encryption is the correct choice.
Mapping table: two to four hours for DBA and/or DevOps lead. TLS on every DB path: one to two person-days for a cert-manager or step-ca setup plus the configuration changes in the application containers. Schema/tenant separation in a historically grown database: 3–10 person-days, depending on migration effort. First-time restore drill: one person-day plus follow-up routine. Backup encryption and data exfiltration detection: 1–3 person-days depending on tool stack. For a mid-sized Sylius or TYPO3 hosting customer, the full implementation comes to 2–3 person-weeks — spread across 8–12 calendar weeks.