Public IT projects need a procurement process and a contract that describe the same operational need. Functionality, information security, data access, intellectual property and a workable exit must be considered before the tender is published.
Define the service and the competition
Separate mandatory functions from features that will earn quality points. Requirements should be objectively linked to the intended use and proportionate. References to a product or technical architecture can restrict competition even without naming a manufacturer. Where alternatives can meet the need, the documents should explain how equivalence will be demonstrated and assessed.
Cloud, data and subcontractors
Identify which data will be processed, who can access them and which subcontractors are involved. A German data centre does not by itself resolve every question about access from another country. The contract should address permitted processing, security measures, incidents, deletion, audit evidence and changes to the supply chain. Confidential tender information also requires protection during procurement.
Pricing, rights and exit
Evaluate implementation, licences, operation, migration and foreseeable exit costs together. Required rights to software, documentation, interfaces and data should be clear. Service levels need measurable obligations and realistic remedies. Renewal options and additional modules should be reflected in the estimated value and the original scope; later changes may require assessment under section 132 GWB.
Prepare the review
Useful documents include the technical specification, architecture, data flows, draft agreement, price model, security requirements and proposed evaluation matrix. The review should identify inconsistencies between these documents and distinguish a desirable commercial term from a mandatory procurement requirement.
Four practical examples
The following scenarios are illustrative, not reports of actual client matters. The outcome depends on the documents and circumstances of the individual procurement.
Example 1: Cloud migration
An authority buys a low-cost cloud service but cannot export its data in a usable format. Define export formats, migration support and deletion evidence before award; otherwise switching costs may undermine the apparent saving.
Example 2: Named product
A specification reproduces one manufacturer’s features. Test whether each restriction follows from the operational need and whether equivalent solutions must be admitted. A familiar product is not automatically the only lawful option.
Example 3: Overseas support
The provider uses support staff outside the EU. Assess actual access, legal safeguards and subcontracting arrangements. Looking only at the physical server location leaves important questions unanswered.
Example 4: New AI module
The contractor offers an additional AI function after award. Check the original options, price effects, data processing and section 132 GWB before ordering it. Technical integration does not establish procurement legality.
Related topics
AI in procurement and purchasing AI systems · Contract modifications and additional public works · Specifications and procurement documents
Discuss your procurement
For a review, please identify the authority, contract or lot, current procedural stage and any deadline. We can then clarify the scope of the requested work. Contact our team. An enquiry does not itself create a retainer or preserve a legal deadline.
Legal sources
Official legislation and materials, some in German: § 31 VgV – Leistungsbeschreibung · § 3 VgV – Auftragswert · DSGVO, insbesondere Art. 28, 32 und 44 ff.
Updated 13 November 2026. Illustrative guidance on German and EU procurement law.