The face of the moon was in shadow
Once an organization has decided it needs a managed secure messaging platform, the next question is where it should run. This is usually presented as a technical choice. It is not. It is a question about who you are willing to depend on, and it has a cost attached that most organizations underestimate in one direction and overestimate in the other.
The four models, plainly
Public cloud
The vendor runs the platform on shared infrastructure and you consume it as a service. You get the best availability, the fastest patching and the lowest operational burden, because the people who wrote the software are the people running it. You give up control of where the data physically sits and which legal regime reaches it.
Private cloud
A dedicated instance, in a jurisdiction you specify, run by the vendor or a hosting partner. You keep most of the operational benefit and gain control of location and tenancy. You pay more, and you are still depending on somebody else's operations team.
Hybrid
Some components in your own environment, others hosted. Usually the sensitive functions (identity, key management, message storage) are held locally while the less sensitive parts are not. It is the most flexible model and the most complex to design, and complexity is itself a security property.
On-premises
The platform runs entirely on infrastructure you own and administer, in a location you choose. Nothing leaves your control. Neither does anything get patched unless somebody on your staff does it.
What actually differs
Strip away the marketing and four things vary between the models.
| Question | Why it matters |
|---|---|
| Where does the data physically sit? | It determines which government can lawfully compel access to it |
| Who administers the platform? | Whoever administers it can change who has access |
| Who patches it, and how quickly? | An unpatched on-premises system is less secure than a maintained cloud one |
| Who is accountable when it fails? | On-premises means the answer is you, at three in the morning |
The mistake that costs the most
It is choosing on-premises for the feeling of control and then not resourcing it.
An on-premises deployment is a system somebody has to run. It needs a server, redundancy, backup, monitoring, someone competent to apply updates, and a plan for what happens when that person leaves. Organizations that specify on-premises to satisfy a policy requirement, then run it on a single unmonitored machine in a comms room, have not gained security. They have moved the risk from a professionally operated data centre onto a box nobody is watching, and made it their own liability at the same time.
If you are going to hold it yourself, hold it properly. If you cannot resource that, private cloud in the right jurisdiction is the honest answer and it is a good one.
What sovereignty actually costs
Organizations budget the licence and forget the rest, so it is worth being explicit. An on-premises deployment carries server hardware or virtual infrastructure, redundancy if availability matters, backup and tested restore, monitoring, a patching routine, and staff time to run all of it. Private cloud removes the hardware and most of the operations but adds a hosting cost and a dependency on the hosting provider's jurisdiction and practices.
The useful comparison is not licence against licence. It is total cost over the life of the deployment, including the staff time nobody puts in the business case. When that is done honestly, private cloud in a specified jurisdiction wins for most organizations that thought they wanted on-premises, and the ones for whom it does not win have a reason they can articulate.
Moving between models later
This is worth asking about before you commit, because the answer varies sharply between platforms.
Some are architected so that the same software runs in all four models and moving is a migration exercise. Others are cloud services with an on-premises variant that behaves differently, and moving means rebuilding. If there is any prospect that your requirement will harden (a new funder condition, a new jurisdiction, a change in the sensitivity of what you hold) establish at selection whether the platform can follow you.
Ask directly: if we start in your cloud and need to move on-premises in two years, what exactly happens to our data, our groups and our history? A clear answer is a good sign in itself.
Federation, which is usually overlooked
There is a fifth option that suits multi-organization work particularly well. Federation lets separate deployments interconnect, so several organizations can communicate as though they were on one system while each retains its own. Nobody becomes the custodian of everybody else's data.
For humanitarian coordination, joint operations, or a lead agency working with implementing partners, that maps onto the actual governance far better than one organization hosting a platform for everybody and quietly acquiring visibility of all of it.
How to choose
Three questions settle most cases.
- Are you subject to a data localisation requirement, or an internal policy that behaves like one? If yes, public cloud is out and the question is private cloud or on-premises.
- Could the data you hold be used to harm the people it describes? If yes, the cost of sovereignty is part of the cost of the programme rather than an optional extra.
- Do you have, and will you keep, the people to operate infrastructure? If not, choose the model that does not require them.
Most organizations that work through those honestly land on private cloud in a specified jurisdiction. A minority genuinely need on-premises, and they usually know why before they ask.
PLACEHOLDER 
AGPO Certified 
