Thousands of people are waiting for their applications to be processed. The system has been down since the morning. The authority calls its IT supplier, who points to the cloud provider, who points to the security partner. Everyone has a contract, but no one has responsibility. This situation is not hypothetical. It is a real example that arises as a result of insufficient preparation of IT projects and inadequate contractual framework.
The following text is based on our long-term experience with cloud projects for public authorities, contributory organisations and state-owned enterprises. We deliberately avoid academic definitions and focus on what determines the success or failure of cloud migration in practice.
The debate on whether cloud belongs in public administration has been concluded long ago. The question today is different: what, and under what legal and contractual conditions, will happen when one day you will want to audit the system, change the supplier or find out who is actually responsible for the fact that the public service is not working.
Cloud projects in the public sector operate in a dense regulatory environment. Additional regulation is coming into play alongside the Public Administration Information Systems Act (ZISVS) and the Cyber Security Act (ZKB), namely the GDPR, the Public Procurement Act, and the growing trend of “cloud sovereignty” at the EU level – evident, for example, in initiatives such as the EUCS (European Union Cloud Scheme) and GAIA-X. Yet the Czech Republic is at a stage where the political will to adopt the cloud is clashing with insufficient legislative and contractual practice.
Cloud for public administration: a product of multiple legal layers
Cloud for private companies is primarily a question of efficiency and cost. Cloud for public authorities is fundamentally different: it is a “legally multi-layered product” where different legal doctrines intersect at each layer.
Each cloud service operated by a public authority must be considered simultaneously from the perspective of several regulations: ZISVS (attestation of public administration information systems, public administration communication infrastructure); ZKB (obligations of regulated service providers and their suppliers); GDPR; the Act on Archives and Records Management; and public procurement rules.
One thing is essential: the responsibility for meeting all these obligations remains with the public authority, regardless of what is “in the cloud”. The cloud is a tool, not a way to absolve oneself of responsibility. This confusion – “we put it in the cloud, now it’s their business” – is behind many of the problems we encounter in our practice.
Two key risks: who is responsible for what, and how to get out of that
“Blurred” responsibility
A typical cloud project in the public sector nowadays involves at least four actors: a hyperscaler (AWS, Azure, GCP) or a local cloud provider, a system integrator, an operator of a specific agenda application or SaaS platform, and a security vendor or SOC. Each of them effectively bears only part of the responsibility. But in many cases, the final contractor is the only party to the contract with the public authority and, logically, disclaims responsibility for the other links in the chain.
If the contract does not contain clear definitions of roles, SLA, and uniform incident management has not been agreed, a problem often arises in practice. The result is a situation where, when the system fails, the public authority has to clarify with the main supplier separately why the problem “is not on the latter’s side” . The remedy is lengthy, the cost of enforcement is high, and meanwhile the public service does not work.
Vendor lock‑in: more sensitive in the public sector than anywhere else
Dependence on one provider is inconvenient everywhere. In the public sector, however, it has specific legal and practical implications.
If further development of the system is only economically or technically possible with the existing provider, the contracting authority is in a deadlock. The contracting authority either proceeds under any conditions (facing the risk of such conduct being challenged), or launches a new procurement procedure which will result in effectively the same situation. Moreover, leaving a provider can be prohibitively expensive if the contract does not specify the data export format, transition interaction, or customisation rights. Moreover, in the event of a provider’s failure or insolvency, the public authority is obliged by operation of law to ensure the continuity of the service, which without a functioning exit plan is usually a crisis scenario with political and legal implications.
What a good cloud contract must include
The legal framework of a cloud project for the public sector is now more of a compliance and governance tool than a classic IT contract. Based on our practical experience, we consider the following areas to be of particular importance:
- Clear description of the service and architecture – who is the actual cloud provider, who is the integrator, where the data physically resides, what is the tenant architecture. Standard product sheets of hyperscalers are not enough.
- SLA and security – incident classification compliant with the ZKB and the contracting authority’s internal security policy, BCP/DR with testable availability, right to audit or acceptance of third-party audits (ISO 27001, SOC 2).
- Personal data protection – clear definition of the roles of controller and processor, transparent sub-processing mechanism, data localisation and rules for international transfers, encryption standards.
- Subcontractor chain – up-to-date list of subcontractors as an annex to the contract, obligation to notify changes well in advance, right of the contracting authority to raise justified objections.
- Exit and data portability – mandatory format and completeness of data export (machine-readable, open standard), length and content of transition services, maximum exit costs agreed in advance, deadlines, and confirmation for deletion of residual copies.
- Protection against unilateral changes in terms – hyperscalers continuously change their standard contractual terms; the contract must contain a regulator change clause and a stabilisation clause in case the change in the provider’s terms jeopardises the performance of the contracting authority’s legal obligations.
Example from practice
A public entity migrates its agenda platform to a SaaS solution. The migration is smooth, the system works. After three years, there is a need to request tenders for functionality extensions – the contracting authority discovers that the customisations made by the integrator are technically inseparable from the platform, the data export format is not standardised, the contract does not include transition services, and the provider’s subcontract chain has changed twice in the meantime without notification. The result is a de facto impossibility to change providers and a severely limited bargaining position.
These situations can be avoided. Key measures include setting data portability and standardised interfaces (APIs) as a condition of the contract, the obligation to document customisations and provide licences for them, establishing transition services as a contractual standard, and regular audits of the subcontractor chain as part of the SLA. None of this is technically complex, but it is important to incorporate these requirements into the tender documentation and contractual framework before the tender is launched.
Conclusion: the biggest risk is not failure, but unauditability
The experience related to cloud projects in the public sector shows a recurring pattern. The biggest risk is not that the system will “crash”. The risk is that it will not be auditable, tenderable and “abandonable” in accordance with law. A good cloud contract today must therefore be first and foremost a compliance and governance tool: it must define responsibilities precisely, ensure auditability and allow the contracting authority to realistically exercise its legal rights in the event that the relationship with the provider becomes complicated.
HAVEL & PARTNERS has long been involved in the legal set-up of cloud projects for public authorities, contributory organisations and regulated entities – from the preparation of tender documentation and evaluation criteria through the contractual framework compliant with the requirements of the ISMS, ZKB and GDPR to the set-up of exit strategies and governance models. If you are preparing a cloud project or reviewing your existing contractual relationships with cloud providers, we will be happy to offer you a practical first-hand perspective.
