Security and sovereignty of consular data
A consular register is a national population file held outside the national territory. It is the most sensitive data a foreign ministry entrusts to a vendor, and the first question it asks — before features, before price.
What sovereignty actually covers
The word covers three distinct requirements, better handled separately: knowing where the data physically resides, knowing who can technically reach it, and being able to take it back without depending on the vendor.
The three call for different guarantees. Poorly administered national hosting protects less than encrypted, logged foreign infrastructure; and impeccable hosting without contractual reversibility still leaves the state captive.
Three deployment models
The choice is not ideological, it follows real constraints: the state's operating capacity, perceived criticality, and running budget.
| Model | What the state controls | What it takes on |
|---|---|---|
| Shared SaaS | Its data, isolated from other missions | None of the operations; lowest cost |
| Dedicated SaaS | Its data and where its instance sits | The cost of an unshared instance |
| On premise | Everything: hardware, network, backups | Operations, upgrades and availability |
Real separation between missions
Data isolation is not an application rule that a filtering mistake can bypass: each mission has its own database schema.
Above it, ministry-level consolidation exists but is read-only. A ministry reads its network; it does not write into a post's cases on its behalf.
End-to-end verifiable authenticity
Every artefact the platform issues — card, document, application form, receipt — carries a cryptographic signature and a QR code. Verification reports it as authentic, cancelled or unknown.
Each verification is itself logged and auditable. A receipt retyped in a word processor does not pass, and an abnormal run of verifications is visible.
Traceability and permissions
- Officer accounts managed per mission, with distinct roles for reviewing, approving, collecting or reading
- Actions logged and attributed to a named officer
- Exceptional acts — fee waiver, reinstating a rejected case — gated behind a dedicated role and a mandatory reason
- A security dashboard listing application events, exportable
Reversibility
A state that doubts it can get its data back will not sign, and it is right to doubt until the guarantee is written down.
A mission's data exports to open office formats without vendor involvement: member register, financial ledger, revenue allocation. Reversibility should be a contract clause as much as a software function — we put it in both.
Frequently asked questions
Where does the data reside?
It depends on the model chosen. In dedicated SaaS as on premise, location is a contract parameter, not a product constraint.
Can one mission see another's data?
No. Separation rests on a distinct database schema per mission, not on an application filter. Only ministry consolidation reads above the posts, read-only.
What if the state wants to change solution?
It exports its data in open formats, with no involvement from us. We recommend writing reversibility into the contract rather than relying on the software function alone.
How are sensitive acts traced?
Actions are logged and attributed to a named officer. Exceptional acts additionally require a dedicated role and a stated reason, which makes them visible to an after-the-fact audit.