Sovereign Cloud Checklist for SMEs: What Counts

For many SMEs, digital sovereignty is still a term floating somewhere between a compliance obligation and an IT strategy, theoretically important, practically unclear. Yet the question is not whether you have to deal with it, but when. GDPR fines, NIS2 requirements and growing customer expectations turn cloud sovereignty into an operational topic. This checklist gives you a concrete basis to assess your cloud situation and make informed decisions.

What digital sovereignty really means for SMEs

Digital sovereignty describes the ability to control yourself where your data lives, who can access it and under which legal system that happens. That sounds simple, but in practice it isn't, precisely because many cloud services deliberately keep these questions blurry.

For an SME, this means concretely: you are responsible for GDPR compliance, even when you use an external cloud provider. And you have to be able to prove that you actually have this control, not just that it's agreed on paper.

Sovereignty is more than a server location

The misconception that holds on most stubbornly: "Our data is in Germany, so we're safe." That's not true, because data residency is not data sovereignty.

What matters is not just where a server stands, but:

• Who has technical access? Even a server in Frankfurt can be operated by a US company that is subject to the CLOUD Act vs. GDPR conflict, and therefore has to grant US authorities access on request.
• How is encryption handled? Are your keys held by the provider or by you?
• What is the operator structure? Is the company running the service European and subject to European law?

These three points are the first layer of every sovereign cloud decision, and the EU's Cloud Sovereignty Framework now makes them formally verifiable.

Why the pressure to act has grown for SMEs

For a long time, cloud sovereignty was mainly relevant for public authorities and large corporations. That has changed.

The GDPR has applied since 2018 to every company that processes personal data, so practically all of them. The requirements for data processing agreements, data transfers to third countries and deletion deadlines are real and are increasingly being actively checked by supervisory authorities.

NIS2 at a glance: who it affects and what to do

The NIS2 directive for DevOps teams, which has applied in Germany since October 2024, significantly expands the circle of affected companies. Anyone with more than 50 employees or operating in one of the defined critical sectors falls under NIS2.

What this means for cloud operations:

• You have to be able to prove security measures in the cloud area
• Incidents have to be reported within 24 hours
• Supply chains, meaning your cloud providers too, have to be checked against security requirements

In short: the era of making cloud decisions purely by price and convenience is over for many SMEs.

The checklist: sovereign cloud for SMEs

Use this list like a small due-diligence process. Ideally, you go through the points together with your cloud provider and ask them for evidence. Once you have the criteria straight, our framework to compare sovereign cloud providers in Germany helps you build a shortlist.

1) Sort out data, workloads and risk cleanly (starting point)

• Data classification in place: Which data sits in the cloud (personal, confidential, intellectual property)? Which categories are critical?
• Workload types captured: Web apps, databases, CI/CD, analytics, backups, logs. What runs where?
• Protection needs defined: Which systems have to be especially available (RTO/RPO, business criticality)?
• Compliance requirements collected: GDPR, industry (e.g. KRITIS-adjacent requirements), customer contracts, internal policies.

2) Legal basis (GDPR & contracts)

• DPA under Art. 28 GDPR signed: With clear TOMs (technical and organizational measures) and up-to-date annexes.
• Role model clear: Who is the controller, who is the processor, is there joint controllership, who is a subprocessor?
• Subprocessor list transparent: Complete, current, with notification and objection mechanisms for changes.
• Third-country transfers assessed: Does any access or transfer happen outside the EU/EEA (support, monitoring, remote admin, telemetry)? If so: legal basis, risk analysis, additional measures.
• Government access and disclosure regulated: What obligations does the provider have for requests? Are there transparency reports, notification duties, legal remedies?
• Exit clauses contractually strong: Data portability, transition periods, migration support, costs, deadlines, deletion, evidence.

3) Location, operator structure and governance (sovereignty at the core)

• Data residency binding: Which data has to stay in the EU, and is that contractually guaranteed?
• Operator structure checked: Who really runs the infrastructure (legal entity, ownership structure, group affiliation)? Which law applies?
• Administrative access limited: Who can administer, from where, under which controls (four-eyes, JIT/JEA, approval flows)?
• Multi-tenancy and isolation traceable: How is tenant isolation implemented (network, storage, IAM)?

4) Security evidence and audits (becoming provable)

• Certifications and scope fit: ISO 27001, BSI C5, SOC 2. Do they cover the specific service (not just the company)?
• Audit documents available: Audit reports, Statement of Applicability, possibly pen-test summaries.
• Security processes documented: Vulnerability management, patch policy, secure SDLC, change management.
• Incident process clear: Reporting channels, response times, forensic support, root-cause analyses.

5) Identities, access and keys (control over access = control over data)

• IAM integration in place: SSO (SAML/OIDC), MFA mandatory, role-based permissions, least privilege.
• Privileged access secured: Admin access only via PAM, time-limited (JIT), logged, with approvals.
• Key management clarified: Who holds the encryption keys? Is BYOK or HYOK possible? Where are the HSMs?
• Encryption in transit and at rest: Technically proven, including backups, snapshots, object storage.
• Secrets management established: No secrets in code. Rotation processes, separation of duties.

6) Logging, monitoring and traceability (audit logs are a duty, not a luxury)

• Audit logs available and exportable: Who did what? Admin actions, API calls, changes to policies.
• Log retention and integrity: Retention, tamper protection, access control, time synchronization.
• Security monitoring integrated: SIEM connection, alerting, use cases (e.g. unusual access, data exfiltration).

7) Architecture: actively avoid portability issues and vendor lock-in

• Open standards preferred: Kubernetes, containers, Terraform/OpenTofu and other IaC tools, OpenTelemetry.
• Proprietary dependencies conscious: Which services are "sticky" (e.g. managed DB with proprietary APIs)? Is there an exit plan?
• Data formats portable: Exports, backups, schema migrations, no proprietary export restrictions.
• Network portability possible: DNS, TLS certificates, IP allowlists, VPN/peering options documented.

8) Backup, recovery and business continuity (sovereignty in an emergency)

• RTO/RPO defined realistically: Per system, signed off by the business unit.
• Backups under your control: Access, export, keys, test restores (not just "backup exists").
• Disaster recovery tested: Regular DR exercises, documented runbooks.
• Geo-redundancy regulated: If used: in which regions, under which law, with which dependencies.

9) Operations, responsibilities and processes in the SME (who does what?)

• Roles assigned internally: Cloud owner, security, data protection, procurement/legal, incident lead, with cloud sovereignty governance owned at board level.
• Operating model clear: Who patches, who escalates, who decides changes, how does deployment run?
• Training and policies: What is allowed in which cloud, how are approvals granted, how are exceptions documented?
• Regular reviews planned: Quarterly security review, annual contract and provider review, change-impact assessments.

10) NIS2 readiness (if relevant)

• Applicability checked and documented: Thresholds, sector, supply chain.
• Risk management established: Policies, responsibilities, catalog of measures, regular assessment.
• Reporting and communication plan: Who reports when, internal communication chain, templates.
• Supply-chain security implemented: Provider assessment, minimum requirements, continuous review.

11) Costs, transparency and the "true cost of compliance"

• Cost structure understandable: Compute, storage, egress, managed services, support, audit/compliance.
• Cost controls active: Budgets, alerts, limits, tagging/cost allocation.
• Compliance effort budgeted: Internal time, audits, documentation, reviews.

12) Exit and migration plan (as a mandatory document)

• Exit plan in writing: Steps, responsibilities, timeline, dependencies.
• Test migration possible: At least one "dry run" for export and restore into an alternative environment.
• Deletion and evidence: Secure deletion after contract end, deletion logs, handling of backups/archives.

Common mistakes in the cloud decision

Four patterns we see again and again:

Price as the only criterion. Cheap cloud services are often cheap because compliance, certifications and sovereign operator structures are missing. Whoever has to migrate afterwards pays more.

The DPA never read. Many SMEs accept template contracts without checking whether they really meet their own GDPR requirements. The devil is often in the annexes here.

Sovereignty assessed only once. Cloud providers change, through acquisitions, new terms, geopolitical developments. What is sovereign today may no longer be tomorrow.

Technical dependencies underestimated. Whoever bets on a single provider's proprietary services from the start has little negotiating power later and high migration costs, which is the core of avoiding cloud vendor lock-in.

Conclusion

In the cloud, digital sovereignty is not a "nice to have" for SMEs, but a question of risk, compliance and ability to act. Whoever sticks to clear criteria, demands evidence and considers portability and exit options from the start avoids expensive wrong decisions. Use the checklist as a repeatable process and review your assumptions regularly, because providers, contracts and regulatory requirements change.