BSI Minimum Standard as a Contract Basis: What Now?

Minimum standards of BSI are not a new tool. The Federal Office specifies the minimum security level that the federal administration must adhere to in specific areas – such as in the use of external cloud services, in logging and detection, in web browsers, in Transport Layer Security, in mobile device management, or in video conferencing services. They are binding for federal authorities and the federal's public IT service providers. With the NIS-2 implementation law that came into effect on December 6, 2025, the BSI Act was revised; the legal basis can now be found in § 44 para. 1 sentence 1 BSIG.

What's new is something else: These standards are moving into procurement. They appear in service descriptions, in EVB-IT contracts, in framework agreements, and in grant notifications. They are moving out of the internal administrative realm. What was a requirement to the authority becomes a contractual performance obligation of the contractor – including proof obligations, audit rights, and, if in doubt, termination and liability consequences.

Not only conventional IT service providers are affected anymore. Those who operate specialized applications, host planning data, provide managed services, connect building control technology, or provide project platforms for public clients now regularly find the clause in their documents.

Minimum standards are written for the operation of an authority, not for a contractual relationship between two parties. They describe roles, processes, and decisions that cannot be transferred one-to-one to a work or service contract. Part of the requirements systematically targets the client – such as determining the need for protection or deciding on the use of a service.

Anyone who nevertheless assures the "compliance with the relevant minimum standards of BSI" takes on obligations that they can neither control nor fulfill.

The pitfalls are similar in almost all procedures:

• Blanket assurance without delineation of responsibility for each requirement.

• Dynamic references "in the current version" without regulation for version changes.

• No agreed form of proof – fulfillment is claimed, but not verifiable.

• Mixing with ISO 27001 or BSI baseline protection without specifying the differences.

• Requirements are not passed through to subcontractors and sub-service providers.

• Deadlines that ignore the actual implementation effort.

The result is rarely a security incident. It is a dispute about responsibilities – usually exactly when an audit is pending or an incident needs to be resolved.

The constructive way is not to negotiate the clause until it is contentless. It is to translate it: from a general reference to a specific, understandable task distribution.

Practically, this means assigning each individual requirement of the relevant minimum standard to a responsibility – client, contractor, or jointly –, accompanying it with a form of proof, and referring it to a specific version with a date. What arises today in many projects as an annex to the contract is essentially a responsibility matrix. It involves a singular effort and saves a significant part of the coordination over the contract's duration.

The effort is also worthwhile for a second reason: minimum standards are well-documented, verifiable, and reusable. Those who have once mapped them cleanly onto their own services have a reliable target image – which can be used again in further procurement procedures and also describes a convincing security level outside of the federal framework.

Referencing a BSI minimum standard is not formalism but a substantive obligation with significant impact. Signing it unchecked shifts an unclear risk into the contract period. Translating it – into concrete requirements, clear responsibilities, and verifiable proofs – yields a double benefit: legal certainty in the ongoing project and a security level that becomes an argument in the next procurement procedure.