Cloud Sovereignty for Swiss Companies

When an employee makes a call in Microsoft Teams, a customer calls the main number, and the CRM automatically opens the contact, data flows through multiple systems. This is precisely where cloud sovereignty becomes a business imperative: It is not the cloud itself that determines control, but rather the question of who actually controls the data, identities, configurations, and communication channels.

For Swiss SMEs, this is more than just a debate about data protection. It’s about accessibility, contractual risks, cost control, and the ability to switch providers or architectures when necessary. Anyone moving their communications, files, and business processes to the cloud should therefore do more than just compare features. What matters most is what dependencies each feature creates.

What "Cloud Sovereignty" Actually Means

Cloud sovereignty describes a company’s ability to use, protect, and further develop its digital resources according to its own rules. This includes data, applications, user accounts, phone numbers, encryption keys, interfaces, and operational processes. A cloud solution can certainly be operated on an international scale. However, it only becomes truly sovereign when a company knows where its critical dependencies lie and how it can maintain its ability to act.

Data storage in Switzerland is an important component, but it is not the whole solution. Even a Swiss data center does not solve the problem if administrators have unrestricted access at the provider’s site, export options are lacking, or important settings can only be changed by submitting a support ticket. Conversely, an international platform is not automatically unsuitable, provided that responsibilities, order processing, access controls, and exit scenarios are clearly defined.

Four Levels of Control

Legal control pertains to contracts, data protection, jurisdiction, and the question of what types of government access are generally permitted. Technical control encompasses encryption, role-based access models, logging, interfaces, and client isolation. Operational control means that the company can manage users, document configurations, and troubleshoot issues. Finally, financial control protects against unforeseen licensing costs, proprietary add-on modules, and a switch that would only be possible with prolonged downtime or high migration costs.

None of these levels stands alone. A perfectly encrypted solution remains problematic if the company lacks an overview of access permissions. An affordable cloud plan can end up being expensive if new license modules are required for every integration, additional security feature, or growing Teams environment.

Cloud Sovereignty in Corporate Communications

When it comes to telephony and collaboration, the starting point is particularly challenging. Communication data is often short-lived but business-critical: call logs, voicemails, call recordings, presence information, contact details, and routing rules reveal who is communicating with whom. If the service goes down or a number isn’t ported correctly, customers and employees feel the impact immediately.

A robust communications architecture therefore raises practical questions. Can the company verifiably prove ownership of the Swiss phone numbers, and can they be ported if the provider is changed? Is Microsoft Teams Is it just a collaboration tool, or is it also a full-fledged telephony channel? Where is the SIP trunk located? Who manages the session border controller, IVR, call queues, and emergency call configuration? And can call data and configurations be exported in a usable format?

Clarity is especially important in hybrid environments. Many organizations use Teams for internal collaboration, a cloud PBX for external calling, and on-premises systems for access control, alarm systems, ERP, or contact centers. This isn’t a drawback. It only becomes problematic when these components grow without documented responsibilities and without coordinated security policies.

Not every workload requires the same cloud

Sovereignty does not mean operating all systems locally. A local phone system can make sense for certain industries, locations with specific requirements, or existing integrations. A hosted PBX, on the other hand, often offers faster scalability, lower operational overhead, and clearly predictable costs. The key is finding the right balance.

For standard collaboration, an established public cloud may be the best choice, both economically and functionally. Critical identities, security protocols, voice routing, or data requiring special protection, on the other hand, may impose stricter requirements on location, access, and operation. Those who ignore these differences either pay for unnecessary complexity or accept risks that can later be corrected only with great effort.

Redundancy is also a matter of balancing priorities. Multiple providers, separate Internet connections, and alternative routing paths increase availability but also entail additional operational and testing costs. For a small office, a clearly defined emergency procedure may be sufficient. For a company with customer service, multiple locations, or an on-call service, redundant connections and a failover-capable telephony architecture are usually a sound investment.

How to Plan for Cloud Sovereignty

The right place to start isn't choosing a product, but taking stock of your current situation. If you carefully follow the steps below, you'll identify gaps early on and be able to clearly articulate your requirements to cloud and communications providers:

• Identify critical services: Document which systems are essential for availability, customer service, identity management, and daily operations. Also take into account hidden dependencies such as DNS, MFA, LDAP, CRM connectors, or network configurations.
• Making data flows visible: Determine where call data, contacts, recordings, backups, and logs are stored, processed, and managed. Support access and subcontractors are also important considerations.
• Consistently organize access rights: Use role-based permissions, multi-factor authentication, and separate administrator accounts. Regularly check which external service providers still have access.
• Review portability from both a contractual and technical perspective: Phone numbers, configuration data, user information, and relevant logs must be exportable. An exit plan is not a sign of mistrust, but rather part of professional procurement.
• Thinking Ahead About Network Security: Cloud services require a reliable foundation consisting of firewall rules, segmented networks, monitored access, and secure SIP connections. A good cloud application is no substitute for network security.
• Testing for malfunctions and shutdowns: Define what in the event of an Internet outage, such as service provider outages, compromised accounts, or a provider switch. Test call forwarding, emergency call routes, backups, and recovery times, rather than relying solely on contractual promises.

This work doesn’t have to result in a major transformation project. Often, clearly prioritized improvements are sufficient: first, secure identities and emergency routing; then, consolidate legacy connections; and finally, standardize Teams telephony and integrations. This reduces risk without slowing down operations.

The architecture must be suited to the operation

Technical freedom is only beneficial if it remains manageable in everyday use. An open interface is worthless if no one documents how to use it. Having your own SBC provides control but requires expertise in certificates, routing, security updates, and monitoring. A fully managed solution reduces these tasks but requires transparent services, clear escalation procedures, and traceable configurations.

For many SMEs, therefore, a managed model makes sense, one in which responsibilities remain clearly defined: The company manages users, rules, and business requirements, while a specialized partner handles infrastructure, security, and operations. Winet, for example, natively integrates Ayrix-PBX and Microsoft Teams without requiring additional Teams add-ons or SBC components that incur licensing fees. While this can reduce licensing and integration costs, it does not replace the need for joint clarification of roles, responsibility for phone numbers, and security requirements.

Documentation is just as important. It should not consist solely of a network diagram, but should also cover phone number blocks, porting information, SIP access credentials, routing rules, administrators, escalation contacts, and recovery procedures. This ensures that knowledge remains within the company, even when employees or service providers change.

Cloud sovereignty is a leadership responsibility

IT is responsible for the technical implementation, but the guidelines come from the business. Executive management and business units must determine which services are mission-critical, what level of data protection is expected, and what costs remain acceptable as the business grows. Procurement should not only compare monthly fees but also evaluate migration, support quality, contract terms, and the ability to integrate with existing processes.

The best next step is to ask those around you an honest question: Could we continue to operate our most important communication and cloud services securely—or switch to alternatives—within a clearly defined timeframe? Where the answer remains unclear, it’s worth conducting a detailed technical and contractual review. That’s precisely where the ability to act—which defines cloud sovereignty in day-to-day business operations—comes into play.