Digital Sovereignty in Public Procurement: Availability Evidence for GovTech Vendors

Since 1 July 2026, German contracting authorities can officially score “digital sovereignty” as an award criterion in public tenders — the new Section 58(2) sentence 2 No. 4 of the German Procurement Ordinance (VgV) turns data localisation, traceability of data processing, and interoperability into scoreable bid attributes. For GovTech vendors selling into the German public sector, this means data residency, C5 alignment, and availability are no longer claims to assert but requirements to evidence with concrete artefacts.

This guide is written for software and SaaS vendors bidding on German public contracts — not for the authorities themselves. It maps the typical requirements from tender documents and the EVB-IT Cloud contract template to the evidence artefact each one calls for, and it draws the line between “providing evidence” and “being procurement-compliant.”

What changed in German procurement law on 1 July 2026?

The Vergabebeschleunigungsgesetz (Procurement Acceleration Act) — approved by the Bundesrat on 8 May 2026, in force since 1 July 2026 — anchors digital sovereignty in procurement law for the first time (BMWE press release, German). Two levers matter for vendors:

• Section 58(2) sentence 2 No. 4 VgV (new): “Aspects of digital sovereignty” can be scored as an award criterion. The legislative reasoning names, among other things, interoperability, traceability of data processing, and data localisation.
• Section 128(2) GWB (Act against Restraints of Competition): digital sovereignty can be set as a contract performance condition — a binding requirement on how the service is delivered.

One limit remains: under Section 127(1) GWB, award criteria must relate to the subject matter of the contract. An authority cannot simply “prefer European vendors” as a blanket policy — but it can very much score where the tendered service’s data lives and how traceable its processing is.

One misconception, cleared up front: the US CLOUD Act does not automatically exclude US vendors from German tenders — no official finding establishes that; it remains an open legal and policy question. In practice, though, the field shifts: once data localisation is scoreable, a documented German or EU data location without third-country access exposure moves from marketing copy to evaluation points. We break down the third-country access problem in our piece on the US CLOUD Act & SaaS monitoring; the EU Jurisdiction Database shows which providers fall under which jurisdiction.

What is EVB-IT Cloud — and when does it apply to you?

EVB-IT — Ergänzende Vertragsbedingungen für die Beschaffung von IT-Leistungen, “supplementary contract terms for the procurement of IT services” — are the German public sector’s standard contract templates for IT purchases, drafted by the Federal Ministry of the Interior / Federal CIO with the industry association Bitkom. For federal agencies, using them is mandatory under administrative regulation No. 4 to Section 55 of the Federal Budget Code (BHO) (Federal CIO, German).

For cloud and SaaS vendors, the key template is the EVB-IT Cloud contract, version 1.0: approved by the IT Planning Council (the federal–state body coordinating public IT) on 11 February 2022 (Resolution 2022/01, German), published on 1 March 2022. It covers IaaS, PaaS, SaaS, and managed cloud services and has three parts: the contract template, the Cloud terms and conditions (Cloud-AGB), and a criteria catalogue (German).

If your tender references the EVB-IT Cloud template — the default for cloud services at federal level and increasingly at state and municipal level — the numbered clauses of the Cloud terms become your contractual obligations. The ones that shape the evidence section of your bid:

• Clause 1.2: services must comply with the basic criteria of the current BSI C5 catalogue plus the authority’s security requirements (the BSI Minimum Standard for external cloud services).
• Clause 4 (place of performance): storage and processing exclusively in the EU/EEA (plus Switzerland under an Article 45 GDPR adequacy decision) — unless the authority explicitly selects additional regions.
• Clause 6.4.1: security evidence on request, including through regular C5 Type 2 reporting.
• Clause 8: availability at the handover point, measured by the contractor; clause 9: monthly reporting on availability and incidents.
• Clauses 7.3, 13.1, 13.3.3: exit — data export at any time in a standard market format, data handover at contract end at no extra charge, and an export interface kept available for 3 months after contract end.

Which tender requirement maps to which evidence artefact?

This is the table to keep next to you while assembling a bid — on the left, the typical requirement from the tender or the EVB-IT Cloud terms; on the right, the artefact that satisfies it:

Typical requirement (source)	Vendor’s evidence artefact
Data location EU/EEA (EVB-IT Cloud terms, clause 4)	Documented hosting location in Germany/EU + complete, current sub-processor list
C5 basic criteria (clause 1.2)	C5 attestation covering the underlying cloud stack (datacenter/IaaS layer) + your own security documentation showing how the basic criteria are covered in your operation
Security evidence on request (clause 6.4.1)	C5 Type 2 report or equivalent security documentation, retrievable without lead time
Availability of at least VK 1 = 99.0% (clause 8.3)	Continuous, independent availability measurement + defensible uptime history per calendar month
Monthly reporting on availability/incidents (clauses 8/9)	Automated availability reports + complete, timestamped incident history
Exit / data handover (clauses 7.3, 13.1, 13.3.3)	Documented data export procedure (format, interface, deadlines)
Data processing agreement	Article 28 GDPR contract (in German practice: AVV) — ideally an instant download, not gated behind a sales call

Two things stand out. First: none of these artefacts can be produced on demand — uptime history, incident documentation, and a sub-processor list have to exist before the tender lands. Second: the artefacts are distinct and not interchangeable — more on that in the C5 section below.

We publish our own DPA the way we would want to receive one from a supplier: as an instant download.

Which availability class do you need to meet — and who measures?

The Cloud terms work with availability classes (Verfügbarkeitsklassen, VK), modelled on the BSI’s high-availability compendium. Calculation per clause 8: (total time − downtime) / total time × 100, with the calendar month as the reference period. A maintenance window on Sundays from 04:00 to 08:00 does not count as downtime.

Class	Availability	Permitted downtime per month
VK 0	≈ 95%	— (base class)
VK 1	99.0%	< 8 hours
VK 2	99.9%	< 44 minutes
VK 3	99.99%	< 5 minutes
VK 4	99.999%	< 26 seconds
VK 5	disaster-tolerant	—

Unless the contract says otherwise, clause 8.3 sets the default at VK 1 — 99.0%.

The decisive detail hides in half a sentence of clause 8: availability is measured by the contractor. You measure yourself, and your numbers are the contractual basis. That is exactly why an internal “our server logs say we were up” is thin in a dispute: it does not measure at the handover point, it has gaps when your own infrastructure is what failed, and it comes from the same hand that owes the SLA. Independent external monitoring — probing your service from the outside, timestamping every incident, computing the monthly figures automatically — turns self-measurement into defensible evidence, and a public status page with uptime history delivers the same proof transparently to the authority. For monitoring tools that are themselves cleanly EU-based, see our overview of European alternatives to US monitoring tools.

What is a C5 attestation — and what is it not?

The BSI’s Cloud Computing Compliance Criteria Catalogue (C5), first published in 2016, defines minimum requirements for secure cloud computing: C5:2020 comprises 121 criteria in 17 domains; the new C5:2026 expands this to 168 criteria in 17 domains (BSI on C5, German). A C5 attestation is not a certification but an audit by a public accountant under ISAE 3000: Type 1 confirms the suitability of controls at a point in time, Type 2 additionally confirms their operating effectiveness over an audit period — the BSI recommends Type 2, and clause 6.4.1 of the Cloud terms explicitly asks for it.

C5 is documented as mandatory in two settings: for federal agencies via the BSI Minimum Standard for external cloud services (German) (issued under Section 8(1) of the BSI Act, version 2.1), and in healthcare via Section 393 SGB V (German): since 1 July 2024, cloud processing of social and health data requires processing in Germany/EU/EEA, a German establishment, and a current C5 attestation — Type 2 mandatory since 1 July 2025. That healthcare regime closely mirrors procurement logic; see our healthcare page for the same evidence stack there. Outside those cases there is no “C5 in every tender” rule — instead, C5 becomes a contractual duty whenever the authority uses the EVB-IT Cloud template (clause 1.2).

For your bid, keep two artefacts strictly apart — they are constantly conflated in practice:

• The C5 attestation is an audit report on the cloud stack — it confirms that the controls of your cloud environment are suitable (Type 1) or operating effectively (Type 2).
• The availability evidence under clauses 8/9 is operational proof — measured uptime, documented incidents, monthly reports.

A C5 attestation does not prove 99.0% availability in March, and a spotless uptime history does not replace a C5 attestation. A tender response needs both — as separate annexes.

For context on where German public IT is heading: the IT Planning Council set the sovereignty course in 2020 with the German Administration Cloud Strategy (Resolution 2020/54, German); the Deutsche Verwaltungscloud has been in production since April 2025 (German). And the amended Online Access Act (“OZG 2.0”, in force since 24 July 2024) creates a legal entitlement to electronic access to federal services from 2028 (Section 1a OZG) — demand for GovTech backed by solid availability and sovereignty evidence will grow structurally (BMI on OZG 2.0, German).

What role does FoundersDeck play — and what role doesn’t it?

The limit first: a monitoring tool does not make your bid procurement-compliant and does not replace a C5 attestation. Procurement readiness is the sum of security documentation, contracts, processes, and evidence — no tool takes that off your plate.

What external monitoring delivers is the operational half of the evidence table above: FoundersDeck continuously probes your services from the outside, records every incident with a timestamp in an incident history, computes availability per calendar month, and publishes it on cookie-free status pages — an independent foundation for the contractor self-measurement under clause 8 and the monthly reporting under clause 9. The infrastructure behind it runs 100% in Germany (Netcup, Nuremberg), operated by a German sole proprietorship with no US corporate ties — and the DPA is an instant download, no sales call. For the data-location row of your own sub-processor list, your monitoring tool then adds another clean EU building block instead of a new risk.

Frequently Asked Questions

Is a BSI C5 attestation mandatory for every German public tender?

No — there is no blanket C5 requirement across all tenders. Two mandatory cases are documented: German federal agencies must apply the BSI Minimum Standard for the use of external cloud services (issued under Section 8(1) of the BSI Act, version 2.1), which requires compliance with the C5 catalogue, and in healthcare, Section 393 of the German Social Code Book V (SGB V) has required a current C5 attestation for cloud processing of social and health data since July 2024 — Type 2 since 1 July 2025. Beyond those cases, C5 becomes a contractual obligation whenever the contracting authority uses the EVB-IT Cloud template: clause 1.2 of its terms and conditions commits the contractor to the basic criteria of the current C5 catalogue. Whether your specific tender requires C5 is decided by the tender documents, not by a general rule.

What does EVB-IT Cloud require for availability — and who measures it?

Clause 8 of the EVB-IT Cloud terms governs availability at the handover point: it is calculated as (total time − downtime) / total time × 100 over a calendar month, and it is measured by the contractor — that is, by you as the vendor, not by the authority. Unless the parties agree otherwise, clause 8.3 sets the default at availability class VK 1, meaning 99.0% (less than 8 hours of downtime per month); a maintenance window on Sundays from 04:00 to 08:00 does not count as downtime. Clause 9 additionally requires monthly reporting on availability and incidents. Because the vendor measures itself, independent external monitoring with a complete, timestamped record is the most credible way to make those self-reported numbers hold up.

Does the US CLOUD Act exclude US vendors from German public tenders?

No — there is no official finding that establishes such an exclusion; this remains an open legal and policy question, not settled law. What is established: clause 4 of the EVB-IT Cloud terms restricts storage and processing to the EU/EEA (plus Switzerland under an Article 45 GDPR adequacy decision), unless the contracting authority explicitly selects additional regions. And since 1 July 2026, authorities can score “aspects of digital sovereignty” as an award criterion under the new Section 58(2) sentence 2 No. 4 of the German Procurement Ordinance (VgV) — according to the legislative reasoning, this includes data localisation and the traceability of data processing. A vendor that can document a clean EU data location without third-country access exposure therefore gains a scoreable advantage, without any competitor being formally excluded.

What does Germany’s 2026 procurement reform change for GovTech vendors?

The Vergabebeschleunigungsgesetz (Procurement Acceleration Act) — approved by the Bundesrat on 8 May 2026 and in force since 1 July 2026 — anchors digital sovereignty in German procurement law for the first time. The new Section 58(2) sentence 2 No. 4 VgV names “aspects of digital sovereignty” as a possible award criterion, with the legislative reasoning citing interoperability, traceability of data processing, and data localisation; in parallel, Section 128(2) of the Act against Restraints of Competition (GWB) allows digital sovereignty to be set as a contract performance condition. One limit remains: award criteria must relate to the subject matter of the contract (Section 127(1) GWB). In practice, this means data location, legal jurisdiction, and exit capability are no longer soft marketing themes — they can flow directly into how bids are scored.

---

This article is for orientation and does not constitute legal or procurement advice; the tender documents and contract wording of each procedure are authoritative. Sources: Federal CIO on EVB-IT Cloud, IT Planning Council Resolution 2022/01 (Cloud terms) and criteria catalogue, BSI C5 introduction, BSI Minimum Standard for external cloud services, Section 393 SGB V, BMWE on the Procurement Acceleration Act, IT Planning Council on the German Administration Cloud, BMI on the amended Online Access Act. Last updated: July 2026.