.png){kind=logo}
The BSI's building blocks carry you to the normal protection level. Where an asset's protection need is classified high or very high (hoher / sehr hoher Schutzbedarf), the methodology asks for supplementary measures — and that is where confidential computing becomes a nameable answer.
Built and operated in Germany.
IT-Grundschutz is the BSI's methodology for building and certifying an information security management system: the BSI standards (200-1 through 200-4) define the method, and the IT-Grundschutz compendium (Kompendium) supplies the building blocks — Bausteine — with concrete requirements for systems, applications, operations and infrastructure. It's the reference model for German public administration, expected of its suppliers, and common ground for KRITIS operators.Two further German terms recur below, and both are worth stating plainly. The information domain (Informationsverbund) is the defined scope of systems, applications, processes and locations your management system covers. The protection need (Schutzbedarf) is the classification — normal, high or very high — you assign to each asset, and it decides how far the methodology pushes you beyond the standard requirements.
Three features of the methodology decide where your effort lands:
Basic and standard requirements are known work. Three situations are structurally hard — where the methodology asks for more than the compendium supplies.
Indicative mapping at building-block (Baustein) level: where enclaive adds enforcement, and the evidence each control gives your audit. German block names are kept as the compendium writes them, with the English reading alongside.
Encryption at rest, in transit and in use: workloads run in hardware-sealed environments with memory encrypted during processing — closing the gap every cryptographic concept quietly leaves open.
Attestation records showing which workloads run encrypted-in-use, continuously.
Technical operator exclusion: when configured with customer-held keys and attestation-based key release, cloud admins and hypervisors have no readable access to workload data, and deployment lands in your own account.
Access-path inventory and key-custody coverage — a cloud treatment that doesn't rest on the provider's word.
Confidential-by-default clusters: pods encapsulated as sealed VMs, control-plane access paths reduced, secrets released only against attestation.
A cluster baseline whose isolation claims are cryptographically checkable.
Pod-level confidential isolation for multi-tenant setups; workload identity and least-privilege access enforced at runtime.
Isolation and identity attestation per workload.
Confidential computing as a nameable, implementable risk-treatment measure where standard requirements end — for exactly the assets the analysis flagged.
Documented supplementary measures with runtime proof, ready for the risk-treatment file.
Evidence packs generated from live operations: attestation status, key custody, access paths — on demand rather than assembled per audit cycle.
A current audit file for the Basis-Sicherheitscheck, the auditor and the re-audit.
BUILDING-BLOCK REFERENCES ARE INDICATIVE POINTERS TO THE COMPENDIUM'S AREAS, NOT A CERTIFICATION CLAIM.
What enclaive does is narrower and more valuable: for the areas above — and especially for the supplementary measures your risk analysis demands at an elevated protection need — it replaces policy-based assurance with technical enforcement, and audit-time evidence hunts with continuous proof. Your modelling stays yours; its hardest technical claims become demonstrable.
What ISMS owners ask
Does deploying enclaive get us certified?
No — certification (ISO 27001 on the basis of IT-Grundschutz) attests to your management system, not to any product. enclaive makes specific technical requirements enforceable and gives the audit verifiable evidence; the methodology, the modelling and the organizational measures remain yours. The box above states the boundary plainly.
Our risk analysis flagged systems at a high protection need (hoher Schutzbedarf). What exactly do we write down?
A supplementary measure the auditor can check: the flagged workloads run in hardware-sealed environments (encryption in use), keys are customer-held and released only against attestation, and infrastructure operators hold no readable access path. Each claim comes with a runtime artifact. The downloadable mapping includes a worked documentation pattern for the risk-treatment file.
Can we use public cloud at all under Grundschutz?
The cloud-usage requirements don't forbid it — they demand a defensible treatment of provider risk, which conventionally means contracts and certificates. Technical operator exclusion changes the quality of that treatment: with customer-held keys and attestation-based release, the provider's admins can't read the workloads, and both facts are checkable. That's a materially stronger answer than a C5 report alone.
How does this relate to BSI C5?
C5 is the BSI's attestation catalogue for cloud providers — it tells you about their controls. IT-Grundschutz is your management system, and your obligations don't transfer to an attested provider. The two compose: C5 covers the provider's side of the shared-responsibility line, and enclaive hardens your side of it, including against the provider itself.
We're certified and NIS2 is coming at us too. Double work?
Less than you'd fear. An IT-Grundschutz management system covers most of what NIS2's organizational measures expect, and the technical controls on this page map onto NIS2's Article 21 areas as well — one enforcement layer, two evidence mappings. See the NIS2 page for that view, and let your legal team settle applicability.
Does the auditor have to take your word for the attestation claims?
No — that's the point. Remote attestation is independently verifiable: the auditor (or the BSI, or your own team) can cryptographically check that the flagged workloads run genuine, unmodified code in genuine sealed environments, at audit time and any other time. Evidence they can execute beats evidence they can only read.
Bring the risk analysis that came back “high”
Tell us where your IT-Grundschutz program stands — the information domain (Informationsverbund), the building blocks in play, the assets your protection-need assessment flagged. We'll show you which supplementary measures close the gaps and what the auditor gets to verify.
